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

[DONE] wml://{security/2015/dla-155.wml}



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

- --- english/security/2015/dla-155.wml	2016-04-09 01:32:24.000000000 +0500
+++ russian/security/2015/dla-155.wml	2016-06-07 15:53:53.364465484 +0500
@@ -1,92 +1,93 @@
- -<define-tag description>LTS security update</define-tag>
+#use wml::debian::translation-check translation="1.3" maintainer="Lev Lamberov"
+<define-tag description>обновление безопаÑ?ноÑ?Ñ?и LTS</define-tag>
 <define-tag moreinfo>
- -<p>This update fixes the CVEs described below.</p>
+<p>Ð? данном обновлении иÑ?пÑ?авленÑ? опиÑ?Ñ?ваемÑ?е ниже CVE.</p>
 
- -<p>A further issue, <a href="https://security-tracker.debian.org/tracker/CVE-2014-9419";>CVE-2014-9419</a>, was considered, but appears to require
- -extensive changes with a consequent high risk of regression.  It is
- -now unlikely to be fixed in squeeze-lts.</p>
+<p>Ð?Ñ?ла Ñ?аÑ?Ñ?моÑ?Ñ?ена еÑ?Ñ? одна пÑ?облема, <a href="https://security-tracker.debian.org/tracker/CVE-2014-9419";>CVE-2014-9419</a>, но, как кажеÑ?Ñ?Ñ?, длÑ?
+еÑ? иÑ?пÑ?авлениÑ? Ñ?Ñ?ебÑ?еÑ?Ñ?Ñ? внеÑ?Ñ?и Ñ?Ñ?Ñ?еÑ?Ñ?веннÑ?е изменениÑ?, имеÑ?Ñ?ие вÑ?Ñ?окий Ñ?иÑ?к поÑ?ледÑ?Ñ?Ñ?ей Ñ?егÑ?еÑ?Ñ?ии.  СкоÑ?ее
+вÑ?его она не бÑ?деÑ? иÑ?пÑ?авлена в squeeze-lts.</p>
 
 <ul>
 
 <li><a href="https://security-tracker.debian.org/tracker/CVE-2013-6885";>CVE-2013-6885</a>
 
- -    <p>It was discovered that under specific circumstances, a combination
- -    of write operations to write-combined memory and locked CPU
- -    instructions may cause a core hang on AMD 16h 00h through 0Fh
- -    processors. A local user can use this flaw to mount a denial of
- -    service (system hang) via a crafted application.</p>
+    <p>Ð?Ñ?ло обнаÑ?Ñ?жено, Ñ?Ñ?о пÑ?и опÑ?еделÑ?ннÑ?Ñ? обÑ?Ñ?оÑ?Ñ?елÑ?Ñ?Ñ?ваÑ? комбинаÑ?иÑ?
+    опеÑ?аÑ?ий запиÑ?и в памÑ?Ñ?Ñ? комбиниÑ?ованной запиÑ?и и блокиÑ?овка инÑ?Ñ?Ñ?Ñ?кÑ?ий
+    ЦÐ? можеÑ? вÑ?зваÑ?Ñ? завиÑ?ание Ñ?дÑ?а пÑ?оÑ?еÑ?Ñ?оÑ?а на пÑ?оÑ?еÑ?Ñ?оÑ?аÑ? AMD 16h Ñ? 00h
+    по 0Fh. Ð?окалÑ?нÑ?й полÑ?зоваÑ?елÑ? можеÑ? иÑ?полÑ?зоваÑ?Ñ? Ñ?Ñ?Ñ? Ñ?Ñ?звимоÑ?Ñ?Ñ? длÑ? вÑ?зова оÑ?каза
+    в обÑ?лÑ?живании (завиÑ?ание Ñ?иÑ?Ñ?емÑ?) Ñ? помоÑ?Ñ?Ñ? Ñ?пеÑ?иалÑ?но Ñ?Ñ?оÑ?миÑ?ованного пÑ?иложениÑ?.</p>
 
- -    <p>For more information please refer to the AMD CPU erratum 793 in
+    <p>Ð?а дополниÑ?елÑ?ной инÑ?оÑ?маÑ?ии обÑ?аÑ?айÑ?еÑ?Ñ? к инÑ?оÑ?маÑ?ии об оÑ?ибкаÑ? AMD CPU номеÑ? 793 по адÑ?еÑ?Ñ?
     <a href="http://support.amd.com/TechDocs/51810_16h_00h-0Fh_Rev_Guide.pdf";>http://support.amd.com/TechDocs/51810_16h_00h-0Fh_Rev_Guide.pdf</a></p></li>
 
 <li><a href="https://security-tracker.debian.org/tracker/CVE-2014-7822";>CVE-2014-7822</a>
 
- -    <p>It was found that the splice() system call did not validate the
- -    given file offset and length. A local unprivileged user can use
- -    this flaw to cause filesystem corruption on ext4 filesystems, or
- -    possibly other effects.</p></li>
+    <p>Ð?Ñ?ло обнаÑ?Ñ?жено, Ñ?Ñ?о Ñ?иÑ?Ñ?емнÑ?й вÑ?зов splice() не вÑ?полнÑ?еÑ? пÑ?овеÑ?кÑ?
+    оÑ?Ñ?Ñ?Ñ?па и длинÑ? данного Ñ?айла. Ð?окалÑ?нÑ?й непÑ?ивилегиÑ?ованнÑ?й полÑ?зоваÑ?елÑ? можеÑ? иÑ?полÑ?зоваÑ?Ñ?
+    Ñ?Ñ?Ñ? Ñ?Ñ?звимоÑ?Ñ?Ñ? длÑ? повÑ?еждениÑ? Ñ?айловой Ñ?иÑ?Ñ?емÑ? на Ñ?азделаÑ? Ñ? Ñ?айловой Ñ?иÑ?Ñ?емой ext4 либо
+    длÑ? дÑ?Ñ?гиÑ? поÑ?енÑ?иалÑ?нÑ?Ñ? дейÑ?Ñ?вий.</p></li>
 
 <li><a href="https://security-tracker.debian.org/tracker/CVE-2014-8133";>CVE-2014-8133</a>
 
- -    <p>It was found that the espfix functionality can be bypassed by
- -    installing a 16-bit RW data segment into GDT instead of LDT (which
- -    espfix checks for) and using it for stack. A local unprivileged user
- -    could potentially use this flaw to leak kernel stack addresses.</p></li>
+    <p>Ð?Ñ?ло обнаÑ?Ñ?жено, Ñ?Ñ?о Ñ?Ñ?нкÑ?ионалÑ?ноÑ?Ñ?Ñ? espfix можно обойÑ?и пÑ?Ñ?Ñ?м
+    Ñ?Ñ?Ñ?ановки 16-биÑ?ного RW-Ñ?егменÑ?а даннÑ?Ñ? в GDT вмеÑ?Ñ?о LDT (Ñ?Ñ?о
+    пÑ?овеÑ?Ñ?еÑ?Ñ?Ñ? espfix) и иÑ?полÑ?зованиÑ? его в каÑ?еÑ?Ñ?ве Ñ?Ñ?ека. Ð?окалÑ?нÑ?й непÑ?ивилегиÑ?ованнÑ?й полÑ?зоваÑ?елÑ?
+    поÑ?енÑ?иалÑ?но можеÑ? иÑ?полÑ?зоваÑ?Ñ? Ñ?Ñ?Ñ? Ñ?Ñ?звимоÑ?Ñ?Ñ? длÑ? вÑ?зова Ñ?Ñ?еÑ?ки адÑ?еÑ?ов Ñ?Ñ?ека Ñ?дÑ?а.</p></li>
 
 <li><a href="https://security-tracker.debian.org/tracker/CVE-2014-8134";>CVE-2014-8134</a>
 
- -    <p>It was found that the espfix functionality is wrongly disabled in
- -    a 32-bit KVM guest. A local unprivileged user could potentially
- -    use this flaw to leak kernel stack addresses.</p></li>
+    <p>Ð?Ñ?ло обнаÑ?Ñ?жено, Ñ?Ñ?о Ñ?Ñ?нкÑ?ионалÑ?ноÑ?Ñ?Ñ? espfix оÑ?ибоÑ?но оÑ?клÑ?Ñ?аеÑ?Ñ?Ñ? в
+    32-биÑ?ной гоÑ?Ñ?евой Ñ?иÑ?Ñ?еме KVM. Ð?окалÑ?нÑ?й непÑ?ивилегиÑ?ованнÑ?й полÑ?зоваÑ?елÑ? поÑ?енÑ?иалÑ?но
+    можеÑ? иÑ?полÑ?зоваÑ?Ñ? Ñ?Ñ?Ñ? Ñ?Ñ?звимоÑ?Ñ?Ñ? длÑ? вÑ?зова Ñ?Ñ?еÑ?ки адÑ?еÑ?ов Ñ?Ñ?ека Ñ?дÑ?а.</p></li>
 
 <li><a href="https://security-tracker.debian.org/tracker/CVE-2014-8160";>CVE-2014-8160</a>
 
- -    <p>It was found that a netfilter (iptables or ip6tables) rule
- -    accepting packets to a specific SCTP, DCCP, GRE or UDPlite
- -    port/endpoint could result in incorrect connection tracking state.
- -    If only the generic connection tracking module (nf_conntrack) was
- -    loaded, and not the protocol-specific connection tracking module,
- -    this would allow access to any port/endpoint of the specified
- -    protocol.</p></li>
+    <p>Ð?Ñ?ло обнаÑ?Ñ?жено, Ñ?Ñ?о пÑ?авило netfilter (iptables или ip6tables),
+    пÑ?инимаÑ?Ñ?ее пакеÑ?Ñ? на оÑ?делÑ?нÑ?Ñ? поÑ?Ñ?аÑ? и конеÑ?нÑ?Ñ? Ñ?оÑ?каÑ? SCTP, DCCP, GRE
+    и UDPlite можеÑ? пÑ?иводиÑ?Ñ? к некоÑ?Ñ?екÑ?номÑ? Ñ?оÑ?Ñ?оÑ?ниÑ? оÑ?Ñ?леживаниÑ? Ñ?оединениÑ?.
+    Ð?Ñ?ли загÑ?Ñ?жен Ñ?олÑ?ко обÑ?ий модÑ?лÑ? оÑ?Ñ?леживаниÑ? Ñ?оединениÑ? (nf_conntrack),
+    а не модÑ?лÑ? оÑ?Ñ?леживаниÑ? Ñ?оединениÑ? длÑ? конкÑ?еÑ?ного пÑ?оÑ?окола,
+    Ñ?о Ñ?Ñ?о можеÑ? позволиÑ?Ñ? полÑ?Ñ?иÑ?Ñ? доÑ?Ñ?Ñ?п к лÑ?бомÑ? поÑ?Ñ?Ñ? или конеÑ?ной Ñ?оÑ?ке Ñ?Ñ?ого
+    пÑ?оÑ?окола.</p></li>
 
 <li><a href="https://security-tracker.debian.org/tracker/CVE-2014-9420";>CVE-2014-9420</a>
 
- -    <p>It was found that the ISO-9660 filesystem implementation (isofs)
- -    follows arbitrarily long chains, including loops, of Continuation
- -    Entries (CEs). This allows local users to mount a denial of
- -    service via a crafted disc image.</p></li>
+    <p>Ð?Ñ?ло обнаÑ?Ñ?жено, Ñ?Ñ?о Ñ?еализаÑ?иÑ? Ñ?айловой Ñ?иÑ?Ñ?емÑ? ISO-9660 (isofs)
+    Ñ?ледÑ?еÑ? по Ñ?епоÑ?кам пÑ?оизволÑ?ной длинÑ? (вклÑ?Ñ?аÑ? Ñ?иклÑ?) пÑ?нкÑ?ов
+    пÑ?одолжениÑ? (CE). ЭÑ?о позволÑ?еÑ? локалÑ?нÑ?м полÑ?зоваÑ?елÑ?м вÑ?зÑ?ваÑ?Ñ? оÑ?каз в
+    обÑ?лÑ?живании Ñ? помоÑ?Ñ?Ñ? Ñ?пеÑ?иалÑ?но Ñ?Ñ?оÑ?миÑ?ованного обÑ?аза диÑ?ка.</p></li>
 
 <li><a href="https://security-tracker.debian.org/tracker/CVE-2014-9584";>CVE-2014-9584</a>
 
- -    <p>It was found that the ISO-9660 filesystem implementation (isofs)
- -    does not validate a length value in the Extensions Reference (ER)
- -    System Use Field, which allows local users to obtain sensitive
- -    information from kernel memory via a crafted disc image.</p></li>
+    <p>Ð?Ñ?ло обнаÑ?Ñ?жено, Ñ?Ñ?о Ñ?еализаÑ?иÑ? Ñ?айловой Ñ?иÑ?Ñ?емÑ? ISO-9660 (isofs)
+    не вÑ?полнÑ?еÑ? пÑ?овеÑ?кÑ? длинÑ? знаÑ?ениÑ? в поле Ñ?иÑ?Ñ?емного иÑ?полÑ?зованиÑ?
+    Ñ?Ñ?Ñ?лок Ñ?аÑ?Ñ?иÑ?ений (ER), Ñ?Ñ?о позволÑ?еÑ? локалÑ?нÑ?м полÑ?зоваÑ?елÑ?м полÑ?Ñ?аÑ?Ñ? Ñ?Ñ?вÑ?Ñ?виÑ?елÑ?нÑ?Ñ?
+    инÑ?оÑ?маÑ?иÑ? из памÑ?Ñ?и Ñ?дÑ?а Ñ? помоÑ?Ñ?Ñ? Ñ?пеÑ?иалÑ?но Ñ?Ñ?оÑ?миÑ?ованного обÑ?аза диÑ?ка.</p></li>
 
 <li><a href="https://security-tracker.debian.org/tracker/CVE-2014-9585";>CVE-2014-9585</a>
 
- -    <p>It was discovered that address randomisation for the vDSO in
- -    64-bit processes is extremely biassed. A local unprivileged user
- -    could potentially use this flaw to bypass the ASLR protection
- -    mechanism.</p></li>
+    <p>Ð?Ñ?ло обнаÑ?Ñ?жено, Ñ?Ñ?о Ñ?андомизаÑ?иÑ? адÑ?еÑ?ов длÑ? vDSO в
+    64-биÑ?нÑ?Ñ? пÑ?оÑ?еÑ?Ñ?аÑ? Ñ?Ñ?езвÑ?Ñ?айно пÑ?едÑ?казÑ?ема. Ð?окалÑ?нÑ?й непÑ?ивилегиÑ?ованнÑ?й полÑ?зоваÑ?елÑ?
+    поÑ?енÑ?иалÑ?но можеÑ? иÑ?полÑ?зоваÑ?Ñ? Ñ?Ñ?Ñ? Ñ?Ñ?звимоÑ?Ñ?Ñ? длÑ? обÑ?ода меÑ?анизма
+    заÑ?иÑ?Ñ? ASLR.</p></li>
 
 <li><a href="https://security-tracker.debian.org/tracker/CVE-2015-1421";>CVE-2015-1421</a>
 
- -    <p>It was found that the SCTP implementation could free
- -    authentication state while it was still in use, resulting in heap
- -    corruption. This could allow remote users to cause a denial of
- -    service or privilege escalation.</p></li>
+    <p>Ð?Ñ?ло обнаÑ?Ñ?жено, Ñ?Ñ?о Ñ?еализаÑ?иÑ? SCTP можеÑ? оÑ?вободиÑ?Ñ? Ñ?оÑ?Ñ?оÑ?ние
+    аÑ?Ñ?енÑ?иÑ?икаÑ?ии в Ñ?о вÑ?емÑ?, как оно еÑ?Ñ? иÑ?полÑ?зÑ?еÑ?Ñ?Ñ?, Ñ?Ñ?о пÑ?иводиÑ? к повÑ?еждениÑ? Ñ?одеÑ?жимого
+    памÑ?Ñ?и. ЭÑ?о можеÑ? позволиÑ?Ñ? Ñ?далÑ?ннÑ?м полÑ?зоваÑ?елÑ?м вÑ?зваÑ?Ñ? оÑ?каз в
+    обÑ?лÑ?живании или повÑ?Ñ?ение пÑ?ивилегий.</p></li>
 
 <li><a href="https://security-tracker.debian.org/tracker/CVE-2015-1593";>CVE-2015-1593</a>
 
- -    <p>It was found that address randomisation for the initial stack in
- -    64-bit processes was limited to 20 rather than 22 bits of entropy.
- -    A local unprivileged user could potentially use this flaw to
- -    bypass the ASLR protection mechanism.</p></li>
+    <p>Ð?Ñ?ло обнаÑ?Ñ?жено, Ñ?Ñ?о Ñ?андомизаÑ?иÑ? адÑ?еÑ?ов наÑ?алÑ?ного Ñ?Ñ?ека в
+    64-биÑ?нÑ?Ñ? пÑ?оÑ?еÑ?Ñ?аÑ? огÑ?аниÑ?ена 20, а не 22 биÑ?ами Ñ?нÑ?Ñ?опии.
+    Ð?окалÑ?нÑ?й непÑ?ивилегиÑ?ованнÑ?й полÑ?зоваÑ?елÑ? поÑ?енÑ?иалÑ?но можеÑ? иÑ?полÑ?зоваÑ?Ñ? Ñ?Ñ?Ñ? Ñ?Ñ?звимоÑ?Ñ?Ñ? длÑ?
+    обÑ?ода меÑ?анизма заÑ?иÑ?Ñ? ASLR.</p></li>
 
 </ul>
 
- -<p>For Debian 6 <q>Squeeze</q>, these issues have been fixed in linux-2.6 version 2.6.32-48squeeze11</p>
+<p>Ð? Debian 6 <q>Squeeze</q> Ñ?Ñ?и пÑ?облемÑ? бÑ?ли иÑ?пÑ?авленÑ? в пакеÑ?е linux-2.6 веÑ?Ñ?ии 2.6.32-48squeeze11</p>
 </define-tag>
 
 # do not modify the following line
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXVqfDAAoJEF7nbuICFtKl2HIP+wfUWb1WbtBZUaBflaXUjbYM
bE9cz7R4XR+voxfwqidjcPXpiBYd1D25NlNpOkj7nhgrLnU+NjDWiFc/hj3fKU2E
68V2s+/1+zZ/ycaIE9p5RZrMUVDewmq7gQHnp+lvpKnva7/6Xd7H2DP5HcJ83Ilq
XjLkrgi0KMHeFpEnOphWBSK/vfEQBSFkKbzRilEC4P67FTEwXuMqw8GKfKETLB5i
8nAPr6bJXjOvkYJifm6SU6feM5rak6Oyt2C8G4nBNrIBSjjOV/NtTKiL3VoM8rZp
+5KJ191ZEDy5EXyMLUUQTs/zAaUfvdMDUrFkE9QKIQAxN2ql+SKW75rG/jGiW0+1
vzPt+ww6jzy9+SIUtSC9TVP/X8be+rK5YMVih51hoaXZoENL6J79jWFmyuKl6Q/X
FnwoqTjOYuBI6GjDJ74aah19AXIfnQYoKhl3TVL6xUdNG74bT+IpVW1lMebERSPU
fCAa0iiPCcEace2MQwYHTFDaY+nFA21leFg6bOQwyBRIXqjkv+XM2lSwQz2aON/U
hbvCi5yySUnoMli2ENidAaCiEwSCpDEVj9O4g64/yJaJbdEQyBnghWIR/eGA1pzo
cqe41I2xWhevUjXqHz4fU7NG0Ehbgif0n0z/j8HNj6DlyX+hQSBxAugCHgjBPTVC
WNMCpVYvTCkBTkQZvXo0
=iEA9
-----END PGP SIGNATURE-----


Reply to: