Re: [DONE] wml://security/2015/dsa-31{64,65,66,68,69,71}.wml

[Vladimir Zhbanov <vzhbanov@gmail.com>]

On Mon, Feb 23, 2015 at 10:53:40PM +0600, Lev Lamberov wrote:
...
> --- english/security/2015/dsa-3169.wml	2015-02-23 21:06:01.000000000 +0500
> +++ russian/security/2015/dsa-3169.wml	2015-02-23 21:49:23.167486748 +0500
> @@ -1,63 +1,65 @@
> -<define-tag description>security update</define-tag>
> +#use wml::debian::translation-check translation="1.2" maintainer="Lev Lamberov"
> +<define-tag description>обновление безопасности</define-tag>
>  <define-tag moreinfo>
> -<p>Several vulnerabilities have been fixed in eglibc, Debian's version of
> -the GNU C library:</p>
> +<p>В eglibc, версии библиотеки GNU C для Debian, были
> +обнаружены несколько уязвимостей:</p>
>  
>  <ul>
>  
>  <li><a href="https://security-tracker.debian.org/tracker/CVE-2012-3406";>CVE-2012-3406</a>
>  
> -    <p>The vfprintf function in stdio-common/vfprintf.c in GNU C Library (aka
> -    glibc) 2.5, 2.12, and probably other versions does not <q>properly restrict
> -    the use of</q> the alloca function when allocating the SPECS array, which
> -    allows context-dependent attackers to bypass the FORTIFY_SOURCE
> -    format-string protection mechanism and cause a denial of service (crash)
> -    or possibly execute arbitrary code via a crafted format string using
> -    positional parameters and a large number of format specifiers, a different
> -    vulnerability than 
> +    <p>Функция vfprintf в stdio-common/vfprintf.c в библиотеке GNU C (известной также как
> +    glibc) 2.5, 2.12, а также вероятно других версий <q>неправильно ограничивает
> +    использование</q> функции alloca при выделении массива SPECS, что
> +    позволяет злоумышленникам обходить механизм защиты форматных строк FORTIFY_SOURCE
> +    и вызывать отказ в обслуживании (аварийная остановка),
> +    либо выполнять произвольный код с помощью специально сформированной форматной строки, использующей
> +    позиционные параметры и большое число спецификаторов формата. Эта уязвимость отличается
> +    от
>      <a href="https://security-tracker.debian.org/tracker/CVE-2012-3404";>\
> -    CVE-2012-3404</a> and 
> +    CVE-2012-3404</a> и от
>      <a href="https://security-tracker.debian.org/tracker/CVE-2012-3405";>\
>      CVE-2012-3405</a>.</p></li>
>  
>  <li><a href="https://security-tracker.debian.org/tracker/CVE-2013-7424";>CVE-2013-7424</a>
>  
> -    <p>An invalid free flaw was found in glibc's getaddrinfo() function when used
> -    with the AI_IDN flag. A remote attacker able to make an application call
> -    this function could use this flaw to execute arbitrary code with the
> -    permissions of the user running the application. Note that this flaw only
> -    affected applications using glibc compiled with libidn support.</p></li>
> +    <p>Проблема с неправильным освобождением была обнаружена в функции getaddrinfo() из glibc при использовании
> +    вместе с флагом AI_IDN. Удалённый злоумышленник, способный заставить приложение вызвать
> +    эту функцию, может использовать данную уязвимость для выполнения произвольного кода с
> +    правами доступа пользователя, запустившего это приложение. Заметьте, что эта уязвимость касается только
> +    тех приложений, которые используют glibc, скомпилированную с поддержкой libidn.</p></li>
>  
>  <li><a href="https://security-tracker.debian.org/tracker/CVE-2014-4043";>CVE-2014-4043</a>
>  
> -    <p>The posix_spawn_file_actions_addopen function in glibc before 2.20 does not
> -    copy its path argument in accordance with the POSIX specification, which
> -    allows context-dependent attackers to trigger use-after-free
> -    vulnerabilities.</p></li>
> +    <p>Функция posix_spawn_file_actions_addopen в glibc до версии 2.20 не
> +    копирует аргумент пути в соответствии со спецификацией POSIX, что
> +    позволяет злоумышленникам использовать уязвимости, проявляющиеся в использовании
> +    указателей после освобождения памяти.</p></li>
>  
>  <li><a href="https://security-tracker.debian.org/tracker/CVE-2014-9402";>CVE-2014-9402</a>
>  
> -    <p>The getnetbyname function in glibc 2.21 or earlier will enter an infinite
> -    loop if the DNS backend is activated in the system Name Service Switch
> -    configuration, and the DNS resolver receives a positive answer while
> -    processing the network name.</p></li>
> +    <p>Функция getnetbyname в glibc 2.21 и более ранних версиях входит в состояние бесконечного
> +    цикла в случае, если в настройке системы Name Service Switch включен
> +    движок DNS, а программа разрешения DNS получает позитивный ответ во время
тут лучше, мне кажется, заменить "позитивный" на "положительный"