[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[DONE] wml://security/2016/dsa-350{0,1}.wml

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

- --- english/security/2016/dsa-3500.wml	2016-03-01 20:55:46.000000000 +0500
+++ russian/security/2016/dsa-3500.wml	2016-03-01 22:11:11.613975304 +0500
@@ -1,74 +1,75 @@
- -<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 were discovered in OpenSSL, a Secure Socket Layer
- -toolkit.</p>
+<p>Ð? OpenSSL, набоÑ?е инÑ?Ñ?Ñ?Ñ?менÑ?ов Secure Socket Layer, бÑ?ло
+обнаÑ?Ñ?жено неÑ?колÑ?ко Ñ?Ñ?звимоÑ?Ñ?ей.</p>
 
 <ul>
 
 <li><a href="https://security-tracker.debian.org/tracker/CVE-2016-0702";>CVE-2016-0702</a>
 
- -    <p>Yuval Yarom from the University of Adelaide and NICTA, Daniel Genkin
- -    from Technion and Tel Aviv University, and Nadia Heninger from the
- -    University of Pennsylvania discovered a side-channel attack which
- -    makes use of cache-bank conflicts on the Intel Sandy-Bridge
- -    microarchitecture. This could allow local attackers to recover RSA
- -    private keys.</p></li>
+    <p>Ювал ЯÑ?ом из УнивеÑ?Ñ?иÑ?еÑ?а Ð?делаидÑ? и NICTA, Ð?Ñ?ниелÑ? Ð?енкин
+    из Technion и УнивеÑ?Ñ?иÑ?еÑ?а ТелÑ?-Ð?вива, а Ñ?акже Ð?адиа ХенингеÑ? из
+    Ð?енÑ?илÑ?ванÑ?кого Ñ?нивеÑ?Ñ?иÑ?еÑ?а обнаÑ?Ñ?жили аÑ?акÑ? Ñ?еÑ?ез Ñ?Ñ?оÑ?онний канал, коÑ?оÑ?аÑ?
+    иÑ?полÑ?зÑ?еÑ? конÑ?ликÑ?Ñ? модÑ?лей кÑ?Ñ?а на микÑ?оаÑ?Ñ?иÑ?екÑ?Ñ?Ñ?е Intel
+    Sandy-Bridge. ЭÑ?а Ñ?Ñ?звимоÑ?Ñ?Ñ? позволÑ?еÑ? локалÑ?нÑ?м злоÑ?мÑ?Ñ?ленникам воÑ?Ñ?Ñ?анавливаÑ?Ñ?
+    закÑ?Ñ?Ñ?Ñ?е клÑ?Ñ?и RSA.</p></li>
 
 <li><a href="https://security-tracker.debian.org/tracker/CVE-2016-0705";>CVE-2016-0705</a>
 
- -    <p>Adam Langley from Google discovered a double free bug when parsing
- -    malformed DSA private keys. This could allow remote attackers to
- -    cause a denial of service or memory corruption in applications
- -    parsing DSA private keys received from untrusted sources.</p></li>
+    <p>Ð?дам Ð?Ñ?нгли из Google обнаÑ?Ñ?жил двойное оÑ?вобождение вÑ?деленной памÑ?Ñ?и, возникаÑ?Ñ?ее пÑ?и
+    вÑ?полнении гÑ?аммаÑ?иÑ?еÑ?кого Ñ?азбоÑ?а некоÑ?Ñ?екÑ?нÑ?Ñ? закÑ?Ñ?Ñ?Ñ?Ñ? клÑ?Ñ?ей DSA. ЭÑ?а Ñ?Ñ?звимоÑ?Ñ?Ñ? можеÑ? позволиÑ?Ñ?
+    Ñ?далÑ?ннÑ?м злоÑ?мÑ?Ñ?ленника вÑ?зваÑ?Ñ? оÑ?каз в обÑ?лÑ?живании или повÑ?еждение Ñ?одеÑ?жимого памÑ?Ñ?и в пÑ?иложениÑ?Ñ?,
+    вÑ?полнÑ?Ñ?Ñ?иÑ? гÑ?аммаÑ?иÑ?еÑ?кий Ñ?азбоÑ? закÑ?Ñ?Ñ?Ñ?Ñ? клÑ?Ñ?ей DSA пÑ?и полÑ?Ñ?ении иÑ? из недовеÑ?еннÑ?Ñ? иÑ?Ñ?оÑ?ников.</p></li>
 
 <li><a href="https://security-tracker.debian.org/tracker/CVE-2016-0797";>CVE-2016-0797</a>
 
- -    <p>Guido Vranken discovered an integer overflow in the BN_hex2bn and
- -    BN_dec2bn functions that can lead to a NULL pointer dereference and
- -    heap corruption. This could allow remote attackers to cause a denial
- -    of service or memory corruption in applications processing hex or
- -    dec data received from untrusted sources.</p></li>
+    <p>Ð?видо Ð?Ñ?анкен обнаÑ?Ñ?жил пеÑ?еполнение Ñ?елÑ?Ñ? Ñ?иÑ?ел в Ñ?Ñ?нкÑ?иÑ?Ñ? BN_hex2bn и
+    BN_dec2bn, коÑ?оÑ?ое можеÑ? пÑ?иводиÑ?Ñ? к Ñ?азÑ?менованиÑ? NULL-Ñ?казаÑ?елÑ? и
+    повÑ?еждениÑ? Ñ?одеÑ?жимого динамиÑ?еÑ?кой памÑ?Ñ?и. ЭÑ?а Ñ?Ñ?звимоÑ?Ñ?Ñ? можеÑ? позволиÑ?Ñ? Ñ?далÑ?ннÑ?м злоÑ?мÑ?Ñ?ленникам
+    вÑ?зваÑ?Ñ? оÑ?каз в обÑ?лÑ?живании в пÑ?иложениÑ?Ñ?, обÑ?абаÑ?Ñ?ваÑ?Ñ?иÑ? Ñ?еÑ?Ñ?надÑ?аÑ?еÑ?иÑ?нÑ?е или деÑ?Ñ?Ñ?еÑ?иÑ?нÑ?е
+    даннÑ?е, полÑ?Ñ?аемÑ?е из недовеÑ?еннÑ?Ñ? иÑ?Ñ?оÑ?ников.</p></li>
 
 <li><a href="https://security-tracker.debian.org/tracker/CVE-2016-0798";>CVE-2016-0798</a>
 
- -    <p>Emilia Käsper of the OpenSSL development team discovered a memory
- -    leak in the SRP database lookup code. To mitigate the memory leak,
- -    the seed handling in SRP_VBASE_get_by_user is now disabled even if
- -    the user has configured a seed. Applications are advised to migrate
- -    to the SRP_VBASE_get1_by_user function.</p></li>
+    <p>ЭмилиÑ? Ð?Ñ?Ñ?пеÑ? из командÑ? Ñ?азÑ?абоÑ?ки OpenSSL обнаÑ?Ñ?жила Ñ?Ñ?еÑ?кÑ? памÑ?Ñ?и
+    в коде поиÑ?ка по базе даннÑ?Ñ? SRP. ЧÑ?обÑ? Ñ?менÑ?Ñ?иÑ?Ñ? вÑ?ед Ñ?Ñ?еÑ?ки памÑ?Ñ?и,
+    бÑ?ла оÑ?клÑ?Ñ?ена обÑ?абоÑ?ка наÑ?алÑ?нÑ?Ñ? Ñ?иÑ?ел в SRP_VBASE_get_by_user даже в Ñ?ом Ñ?лÑ?Ñ?ае, еÑ?ли
+    полÑ?зоваÑ?елÑ? наÑ?Ñ?Ñ?оил наÑ?алÑ?ное Ñ?иÑ?ло. РекомендÑ?еÑ?Ñ?Ñ? пеÑ?евеÑ?Ñ?и пÑ?иложениÑ?
+    на иÑ?полÑ?зование Ñ?Ñ?нкÑ?ии SRP_VBASE_get1_by_user.</p></li>
 
 <li><a href="https://security-tracker.debian.org/tracker/CVE-2016-0799";>CVE-2016-0799</a>
 
- -    <p>Guido Vranken discovered an integer overflow in the BIO_*printf
- -    functions that could lead to an OOB read when printing very long
- -    strings. Additionally the internal doapr_outch function can attempt
- -    to write to an arbitrary memory location in the event of a memory
- -    allocation failure. These issues will only occur on platforms where
- -    sizeof(size_t) > sizeof(int) like many 64 bit systems. This could
- -    allow remote attackers to cause a denial of service or memory
- -    corruption in applications that pass large amounts of untrusted data
- -    to the BIO_*printf functions.</p></li>
+    <p>Ð?видо Ð?Ñ?анкен обнаÑ?Ñ?жил пеÑ?еполнение Ñ?елÑ?Ñ? Ñ?иÑ?ел в Ñ?Ñ?нкÑ?иÑ?Ñ? BIO_*printf,
+    коÑ?оÑ?ое можеÑ? пÑ?иводиÑ?Ñ? к Ñ?Ñ?ениÑ? OOB пÑ?и вÑ?воде на пеÑ?аÑ?Ñ? оÑ?енÑ? длиннÑ?Ñ?
+    Ñ?Ñ?Ñ?ок. Ð?Ñ?оме Ñ?ого, внÑ?Ñ?Ñ?еннÑ?Ñ? Ñ?Ñ?нкÑ?иÑ? doapr_outch можеÑ? попÑ?Ñ?аÑ?Ñ?Ñ?Ñ?
+    вÑ?полниÑ?Ñ? запиÑ?Ñ? в пÑ?оизволÑ?нÑ?Ñ? облаÑ?Ñ?Ñ? памÑ?Ñ?и в Ñ?лÑ?Ñ?ае возникновениÑ? оÑ?ибки
+    вÑ?делениÑ? памÑ?Ñ?и. ЭÑ?и пÑ?облемÑ? вÑ?Ñ?Ñ?еÑ?аÑ?Ñ?Ñ?Ñ? Ñ?олÑ?ко на плаÑ?Ñ?оÑ?маÑ?, где
+    sizeof(size_t) > sizeof(int) (как на многиÑ? 64-биÑ?нÑ?Ñ? Ñ?иÑ?Ñ?емаÑ?). ЭÑ?а Ñ?Ñ?звимоÑ?Ñ?Ñ? можеÑ?
+    позволиÑ?Ñ? Ñ?далÑ?ннÑ?м злоÑ?мÑ?Ñ?ленникам вÑ?зÑ?ваÑ?Ñ? оÑ?каз в обÑ?лÑ?живании или повÑ?еждение Ñ?одеÑ?жимого
+    памÑ?Ñ?и в пÑ?иложениÑ?Ñ?, коÑ?оÑ?Ñ?е пеÑ?едаÑ?Ñ? болÑ?Ñ?ое колиÑ?еÑ?Ñ?во недовеÑ?еннÑ?Ñ? даннÑ?Ñ?
+    Ñ?Ñ?нкÑ?иÑ?м BIO_*printf.</p></li>
 
 </ul>
 
- -<p>Additionally the EXPORT and LOW ciphers were disabled since thay could
- -be used as part of the DROWN 
- -(<a href="https://security-tracker.debian.org/tracker/CVE-2016-0800";>CVE-2016-0800</a>) 
- -and SLOTH 
- -(<a href="https://security-tracker.debian.org/tracker/CVE-2015-7575";>CVE-2015-7575</a>)
- -attacks, but note that the oldstable (wheezye) and stable (jessie)
- -distributions are not affected by those attacks since the SSLv2 protocol
- -has already been dropped in the openssl package version 1.0.0c-2.</p>
- -
- -<p>For the oldstable distribution (wheezy), these problems have been fixed
- -in version 1.0.1e-2+deb7u20.</p>
+<p>Ð?Ñ?оме Ñ?ого, бÑ?ли оÑ?клÑ?Ñ?енÑ? Ñ?иÑ?Ñ?Ñ? EXPORT и LOW, поÑ?колÑ?кÑ? они могÑ?Ñ?
+иÑ?полÑ?зоваÑ?Ñ?Ñ?Ñ? в каÑ?еÑ?Ñ?ве Ñ?аÑ?Ñ?и аÑ?ак DROWN
+(<a href="https://security-tracker.debian.org/tracker/CVE-2016-0800";>CVE-2016-0800</a>)
+и SLOTH
+(<a href="https://security-tracker.debian.org/tracker/CVE-2015-7575";>CVE-2015-7575</a>),
+но замеÑ?Ñ?Ñ?е, Ñ?Ñ?о пÑ?едÑ?дÑ?Ñ?ий Ñ?Ñ?абилÑ?нÑ?й (wheezy) и Ñ?Ñ?абилÑ?нÑ?й (jessie)
+вÑ?пÑ?Ñ?ки не подвеÑ?женÑ? Ñ?Ñ?им аÑ?акам, Ñ?ак как пÑ?оÑ?окол SSLv2 Ñ?же
+бÑ?л вÑ?клÑ?Ñ?ен в пакеÑ?е openssl веÑ?Ñ?ии 1.0.0c-2.</p>
+
+<p>Ð? пÑ?едÑ?дÑ?Ñ?ем Ñ?Ñ?абилÑ?ном вÑ?пÑ?Ñ?ке (wheezy) Ñ?Ñ?и пÑ?облемÑ? бÑ?ли иÑ?пÑ?авленÑ?
+в веÑ?Ñ?ии 1.0.1e-2+deb7u20.</p>
 
- -<p>For the stable distribution (jessie), these problems have been fixed in
- -version 1.0.1k-3+deb8u4.</p>
+<p>Ð? Ñ?Ñ?абилÑ?ном вÑ?пÑ?Ñ?ке (jessie) Ñ?Ñ?и пÑ?облемÑ? бÑ?ли иÑ?пÑ?авленÑ? в
+веÑ?Ñ?ии 1.0.1k-3+deb8u4.</p>
 
- -<p>For the unstable distribution (sid), these problems will be fixed shortly.</p>
+<p>Ð? неÑ?Ñ?абилÑ?ном вÑ?пÑ?Ñ?ке (sid) Ñ?Ñ?и пÑ?облемÑ? бÑ?дÑ?Ñ? иÑ?пÑ?авленÑ? в Ñ?коÑ?ом вÑ?емени.</p>
 
- -<p>We recommend that you upgrade your openssl packages.</p>
+<p>РекомендÑ?еÑ?Ñ?Ñ? обновиÑ?Ñ? пакеÑ?Ñ? openssl.</p>
 </define-tag>
 
 # do not modify the following line
- --- english/security/2016/dsa-3501.wml	2016-03-01 21:04:27.688825435 +0500
+++ russian/security/2016/dsa-3501.wml	2016-03-01 22:20:31.119215656 +0500
@@ -1,33 +1,34 @@
- -<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>Stephane Chazelas discovered a bug in the environment handling in Perl.
- -Perl provides a Perl-space hash variable, %ENV, in which environment
- -variables can be looked up.  If a variable appears twice in envp, only
- -the last value would appear in %ENV, but getenv would return the first.
- -Perl's taint security mechanism would be applied to the value in %ENV,
- -but not to the other rest of the environment.  This could result in an
- -ambiguous environment causing environment variables to be propagated to
- -subprocesses, despite the protections supposedly offered by taint
- -checking.</p>
+<p>СÑ?еÑ?ан ШезалаÑ? обнаÑ?Ñ?жил оÑ?ибкÑ? в коде обÑ?абоÑ?ки окÑ?Ñ?жениÑ? в Perl.
+Perl пÑ?едоÑ?Ñ?авлÑ?еÑ? Ñ?Ñ?Ñ?-пеÑ?еменнÑ?Ñ? пÑ?оÑ?Ñ?Ñ?анÑ?Ñ?ва Perl, %ENV, в коÑ?оÑ?ой можно
+пÑ?оÑ?моÑ?Ñ?еÑ?Ñ? пеÑ?еменнÑ?е окÑ?Ñ?жениÑ?.  Ð?Ñ?ли пеÑ?еменнаÑ? дваждÑ? вÑ?Ñ?Ñ?еÑ?аеÑ?Ñ?Ñ? в envp, Ñ?о
+в %ENV попадаеÑ? Ñ?олÑ?ко поÑ?леднее знаÑ?ение, Ñ?оÑ?Ñ? getenv возвÑ?аÑ?аеÑ? пеÑ?вое.
+Ð?еÑ?анизм безопаÑ?ноÑ?Ñ?и Perl пÑ?именÑ?еÑ?Ñ?Ñ? к знаÑ?ениÑ? в %ENV,
+но не к дÑ?Ñ?гой Ñ?аÑ?Ñ?и окÑ?Ñ?жениÑ?.  ЭÑ?о пÑ?иводиÑ? к
+неоднознаÑ?номÑ? окÑ?Ñ?жениÑ?, вÑ?зÑ?ваÑ? пеÑ?едаÑ?Ñ? пеÑ?еменнÑ?Ñ? окÑ?Ñ?жениÑ?
+подпÑ?оÑ?еÑ?Ñ?ам, неÑ?моÑ?Ñ?Ñ? на заÑ?иÑ?Ñ?, пÑ?едполагаемÑ?е пÑ?овеÑ?кой
+заÑ?азноÑ?Ñ?и.</p>
 
- -<p>With this update Perl changes the behavior to match the following:</p>
+<p>Ð?анное обновление Perl изменÑ?еÑ? поведение Ñ?ледÑ?Ñ?Ñ?им обÑ?азом:</p>
 
 <ol type="a">
- -    <li>%ENV is populated with the first environment variable, as getenv
- -        would return.</li>
- -    <li>Duplicate environment entries are removed.</li>
+    <li>%ENV заÑ?елÑ?еÑ?Ñ?Ñ? пеÑ?вой пеÑ?еменной окÑ?Ñ?жениÑ?, коÑ?оÑ?аÑ? возвÑ?аÑ?аеÑ?Ñ?Ñ?
+        getenv.</li>
+    <li>Ð?Ñ?блиÑ?Ñ?Ñ?Ñ?ие запиÑ?и окÑ?Ñ?жениÑ? Ñ?далÑ?Ñ?Ñ?Ñ?Ñ?.</li>
 </ol>
 
- -<p>For the oldstable distribution (wheezy), this problem has been fixed
- -in version 5.14.2-21+deb7u3.</p>
+<p>Ð? пÑ?едÑ?дÑ?Ñ?ем Ñ?Ñ?абилÑ?ном вÑ?пÑ?Ñ?ке (wheezy) Ñ?Ñ?а пÑ?облема бÑ?ла иÑ?пÑ?авлена
+в веÑ?Ñ?ии 5.14.2-21+deb7u3.</p>
 
- -<p>For the stable distribution (jessie), this problem has been fixed in
- -version 5.20.2-3+deb8u4.</p>
+<p>Ð? Ñ?Ñ?абилÑ?ном вÑ?пÑ?Ñ?ке (jessie) Ñ?Ñ?а пÑ?облема бÑ?ла иÑ?пÑ?авлена в
+веÑ?Ñ?ии 5.20.2-3+deb8u4.</p>
 
- -<p>For the unstable distribution (sid), this problem will be fixed in
- -version 5.22.1-8.</p>
+<p>Ð? неÑ?Ñ?абилÑ?ном вÑ?пÑ?Ñ?ке (sid) Ñ?Ñ?а пÑ?облема бÑ?деÑ? иÑ?пÑ?авлена в
+веÑ?Ñ?ии 5.22.1-8.</p>
 
- -<p>We recommend that you upgrade your perl packages.</p>
+<p>РекомендÑ?еÑ?Ñ?Ñ? обновиÑ?Ñ? пакеÑ?Ñ? perl.</p>
 </define-tag>
 
 # do not modify the following line
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJW1c+GAAoJEF7nbuICFtKlIFkP+wZzipGKbfvbCG2CG0d1Xp+B
pGFVrKbZj8caQJO069gJK7bEbCVhwGbPFjvvooa/AY8CVnWW6HzR5M3U3f8+DmPt
uzeme3UQw0OFc1oBMk8mX84uCJ3gG4+7y/aF2Yw8c/4JF/NSW5qdgMqTgg/YwJ7H
O3YvI42lXddSSxvzqEbjjH+4Is0qvqYlRZZxfx0YRf3AwudHfWuCCgZLavvOF4FN
FoXzrao8pUUz486eBqVz5wIQXAfMu4d5hmOcf+epaNjDXzzc3criakpRqBI6SVdp
4ABH2CLloaUukQyNG0Vf+EJeY2DFMY5D/xykE6U7da8GJsB1Z5OepxdHauimPVmL
V43BKuVN7tOqMZgkMs0qdSamcnDngp2uhHUYkZMuAHVgdTGLMJxbs2WgjfvJn2Ya
Ib2ZZQ0qoyGFxTR8mFWaTEbMdvs6L3P0x8ldNsSyniSyeyVmhd3A0hteuimq4jM6
6fEpDcz6VLUBkF+vjD9H9/1Cfs6ENQwqQp3vEeQpK2QGcvkANqn+FWCwHAjkyCRx
cHiJkLD+vat+AsKtX/x3cuTORjU8dc9tDtEifNcfIZrlh83PrJvBI4ImlmYYk/km
c8+RPIrU+dJ+VlRvIY/KI1wiEm9OzfEaWj8EyzcqGIV1eU+9ZUZ4gM6GxQDlmsao
YFq0+utOh4Ox/7Q6hukn
=gRiG
-----END PGP SIGNATURE-----
Reply to: