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

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

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

- --- english/security/2015/dla-192.wml	2016-04-07 03:47:55.000000000 +0500
+++ russian/security/2015/dla-192.wml	2016-05-31 11:59:21.293283533 +0500
@@ -1,44 +1,45 @@
- -<define-tag description>LTS security update</define-tag>
+#use wml::debian::translation-check translation="1.2" maintainer="Lev Lamberov"
+<define-tag description>обновление безопаÑ?ноÑ?Ñ?и LTS</define-tag>
 <define-tag moreinfo>
 <ul>
 
 <li><a href="https://security-tracker.debian.org/tracker/CVE-2015-1798";>CVE-2015-1798</a>
 
- -    <p>When ntpd is configured to use a symmetric key to authenticate a remote NTP
- -    server/peer, it checks if the NTP message authentication code (MAC) in received
- -    packets is valid, but not if there actually is any MAC included. Packets without
- -    a MAC are accepted as if they had a valid MAC. This allows a MITM attacker to
- -    send false packets that are accepted by the client/peer without having to know
- -    the symmetric key. The attacker needs to know the transmit timestamp of the
- -    client to match it in the forged reply and the false reply needs to reach the
- -    client before the genuine reply from the server. The attacker doesn't
- -    necessarily need to be relaying the packets between the client and the server.</p>
- -
- -    <p>Authentication using autokey doesn't have this problem as there is a check that
- -    requires the key ID to be larger than NTP_MAXKEY, which fails for packets
- -    without a MAC.</p></li>
+    <p>Ð?Ñ?ли ntpd наÑ?Ñ?Ñ?оен на иÑ?полÑ?зование Ñ?иммеÑ?Ñ?иÑ?нÑ?Ñ? клÑ?Ñ?ей длÑ? аÑ?Ñ?енÑ?иÑ?икаÑ?ии Ñ?далÑ?нного NTP
+    Ñ?еÑ?веÑ?а или одноÑ?ангового Ñ?зла, Ñ?о он пÑ?овеÑ?Ñ?еÑ? пÑ?авилÑ?ноÑ?Ñ?Ñ? кода аÑ?Ñ?енÑ?иÑ?икаÑ?ии (MAC) Ñ?ообÑ?ениÑ? NTP в
+    полÑ?Ñ?еннÑ?Ñ? пакеÑ?аÑ?, но не Ñ?о, имееÑ?Ñ?Ñ? ли вообÑ?е какой-либо MAC. Ð?акеÑ?Ñ? без
+    MAC пÑ?инимаÑ?Ñ?Ñ?Ñ? как пакеÑ?Ñ?, Ñ?одеÑ?жаÑ?ие пÑ?авилÑ?нÑ?й MAC. ЭÑ?о позволÑ?еÑ? злоÑ?мÑ?Ñ?ленникÑ? MITM,
+    не имеÑ? Ñ?иммеÑ?Ñ?иÑ?ного клÑ?Ñ?а, оÑ?пÑ?авлÑ?Ñ?Ñ? ложнÑ?е пакеÑ?Ñ?, коÑ?оÑ?Ñ?е пÑ?инимаÑ?Ñ?Ñ?Ñ?
+    клиенÑ?ом или одноÑ?анговÑ?м Ñ?злом. Ð?лоÑ?мÑ?Ñ?ленникÑ? нÑ?жно знаÑ?Ñ? вÑ?еменнÑ?Ñ? оÑ?меÑ?кÑ? пеÑ?едаÑ?и,
+    Ñ?Ñ?обÑ? оÑ?меÑ?ка в его подделÑ?ном оÑ?веÑ?е Ñ?ооÑ?веÑ?Ñ?Ñ?вовала еÑ?, а ложнÑ?й оÑ?веÑ? должен дойÑ?и до
+    клиенÑ?а Ñ?анÑ?Ñ?е оÑ?веÑ?а наÑ?Ñ?оÑ?Ñ?его Ñ?еÑ?веÑ?а. Ð?лоÑ?мÑ?Ñ?ленникÑ? не обÑ?заÑ?елÑ?но
+    вÑ?полнÑ?Ñ?Ñ? Ñ?олÑ? пеÑ?едаÑ?Ñ?ика пакÑ?ов междÑ? клиенÑ?ом и Ñ?еÑ?веÑ?ом.</p>
+
+    <p>Ð?Ñ?Ñ?енÑ?иÑ?икаÑ?иÑ?, иÑ?полÑ?зÑ?Ñ?Ñ?аÑ? авÑ?оклÑ?Ñ?, не подвеÑ?жена Ñ?Ñ?ой пÑ?облеме, поÑ?колÑ?кÑ? в ней имееÑ?Ñ?Ñ? пÑ?овеÑ?ка,
+    Ñ?Ñ?ебÑ?Ñ?Ñ?аÑ?, Ñ?Ñ?обÑ? иденÑ?иÑ?икаÑ?оÑ? клÑ?Ñ?а бÑ?л болÑ?Ñ?е NTP_MAXKEY. ЭÑ?о Ñ?Ñ?ловие не вÑ?полнÑ?еÑ?Ñ?Ñ? длÑ?
+    пакеÑ?ов, не имеÑ?Ñ?иÑ? MAC.</p></li>
 
 <li><a href="https://security-tracker.debian.org/tracker/CVE-2015-1799";>CVE-2015-1799</a>
 
- -    <p>An attacker knowing that NTP hosts A and B are peering with each other
- -    (symmetric association) can send a packet to host A with source address of B
- -    which will set the NTP state variables on A to the values sent by the attacker.
- -    Host A will then send on its next poll to B a packet with originate timestamp
- -    that doesn't match the transmit timestamp of B and the packet will be dropped.
- -    If the attacker does this periodically for both hosts, they won't be able to
- -    synchronize to each other. This is a known denial-of-service attack, described
- -    at <a href="https://www.eecis.udel.edu/~mills/onwire.html";>https://www.eecis.udel.edu/~mills/onwire.html</a> .</p>
- -
- -    <p>According to the document the NTP authentication is supposed to protect
- -    symmetric associations against this attack, but that doesn't seem to be the
- -    case. The state variables are updated even when authentication fails and the
- -    peers are sending packets with originate timestamps that don't match the
- -    transmit timestamps on the receiving side.</p>
+    <p>Ð?лоÑ?мÑ?Ñ?ленник, знаÑ?Ñ?ий, Ñ?Ñ?о NTP-Ñ?злÑ? A и B взаимодейÑ?Ñ?вÑ?Ñ?Ñ? дÑ?Ñ?г Ñ? дÑ?Ñ?гом
+    (Ñ?иммеÑ?Ñ?иÑ?наÑ? аÑ?Ñ?оÑ?иаÑ?иÑ?), можеÑ? оÑ?пÑ?авиÑ?Ñ? пакеÑ? Ñ?злÑ? A Ñ? адÑ?еÑ?ом иÑ?Ñ?оÑ?ника B,
+    Ñ?Ñ?о пÑ?иведÑ?Ñ? к Ñ?Ñ?Ñ?ановке пеÑ?еменнÑ?Ñ? Ñ?оÑ?Ñ?оÑ?ниÑ? NTP на A в знаÑ?ениÑ?, оÑ?пÑ?авленнÑ?е злоÑ?мÑ?Ñ?ленником.
+    Ð?аÑ?ем Ñ?зел A пÑ?и Ñ?ледÑ?Ñ?Ñ?ем опÑ?оÑ?е оÑ?пÑ?авиÑ? B пакеÑ? Ñ? иниÑ?ииÑ?ованной вÑ?еменной оÑ?меÑ?кой,
+    коÑ?оÑ?аÑ? не Ñ?овпадаеÑ? Ñ? вÑ?еменной оÑ?меÑ?ки пеÑ?едаÑ?и B, и Ñ?Ñ?оÑ? пакеÑ? бÑ?деÑ? Ñ?бÑ?оÑ?ен.
+    Ð?Ñ?ли злоÑ?мÑ?Ñ?ленник пеÑ?иодиÑ?еÑ?ки вÑ?полнÑ?еÑ? Ñ?казаннÑ?е дейÑ?Ñ?виÑ? на двÑ?Ñ? Ñ?злаÑ?, Ñ?о они не Ñ?могÑ?Ñ?
+    Ñ?инÑ?Ñ?онизиÑ?оваÑ?Ñ?Ñ?Ñ? дÑ?Ñ?г Ñ? дÑ?Ñ?гом. ЭÑ?а Ñ?иÑ?Ñ?аÑ?иÑ? извеÑ?Ñ?наÑ? как оÑ?каз в обÑ?лÑ?живании и бÑ?ла
+    опиÑ?ана в <a href="https://www.eecis.udel.edu/~mills/onwire.html";>https://www.eecis.udel.edu/~mills/onwire.html</a> .</p>
+
+    <p>СоглаÑ?но Ñ?Ñ?омÑ? докÑ?менÑ?Ñ?, аÑ?Ñ?енÑ?иÑ?икаÑ?иÑ? NTP должна заÑ?иÑ?аÑ?Ñ?
+    Ñ?иммеÑ?Ñ?иÑ?нÑ?е аÑ?Ñ?оÑ?иаÑ?ии оÑ? Ñ?Ñ?ой аÑ?аки, но Ñ?Ñ?о не
+    Ñ?ак. Ð?еÑ?еменнÑ?е Ñ?оÑ?Ñ?оÑ?ниÑ? обновлÑ?Ñ?Ñ?Ñ?Ñ? даже в Ñ?ом Ñ?лÑ?Ñ?ае, когда аÑ?Ñ?енÑ?иÑ?икаÑ?иÑ? завеÑ?Ñ?илаÑ?Ñ? неÑ?даÑ?но,
+    а одноÑ?анговÑ?е Ñ?злÑ? оÑ?пÑ?авлÑ?Ñ?Ñ? пакеÑ?Ñ? Ñ? иниÑ?ииÑ?ованнÑ?ми вÑ?еменнÑ?ми оÑ?меÑ?ками, коÑ?оÑ?Ñ?е не Ñ?овпадаÑ?Ñ?
+    Ñ? вÑ?еменнÑ?ми оÑ?меÑ?ками пеÑ?едаÑ?и на полÑ?Ñ?аÑ?Ñ?ей Ñ?Ñ?оÑ?оне.</p>
 
- -<p>ntp-keygen on big endian hosts</p>
+<p>ntp-keygen на Ñ?злаÑ? Ñ? поÑ?Ñ?дком байÑ?ов оÑ? младÑ?его к Ñ?Ñ?аÑ?Ñ?емÑ?</p>
 
- -    <p>Using ntp-keygen to generate an MD5 key on big endian hosts resulted in
- -    either an infite loop or an key of only 93 possible keys.</p></li>
+    <p>Ð?Ñ?полÑ?зование ntp-keygen длÑ? Ñ?озданиÑ? клÑ?Ñ?а MD5 на Ñ?злаÑ? Ñ? поÑ?Ñ?дком байÑ?ов оÑ? младÑ?его к Ñ?Ñ?аÑ?Ñ?емÑ? пÑ?иводиÑ?
+    либо к возникновениÑ? беÑ?конеÑ?ного Ñ?икла, либо к Ñ?омÑ?, Ñ?Ñ?о Ñ?оздаÑ?Ñ?Ñ?Ñ? клÑ?Ñ? из лиÑ?Ñ? 93 возможнÑ?Ñ? клÑ?Ñ?ей.</p></li>
 
 </ul>
 </define-tag>
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXTTZMAAoJEF7nbuICFtKl3bgP/1OPjEoOahuw5D0qODJ+goo0
y1BzoPZbz0zMHQoZay1l4H2y6FtqkrZxTx3T2mOD8L8IjUGhPPFvF5Pgago3BXhQ
nMcSkpC5flDnNtgdqORzaw3ye1Fj19XMFZiBKwyPTd/BVxKozVZz3jw757hZhMQK
E81inQVEYGb0PSfOTlVENvxBx6dsB/nUmcOCaylkkOaQGJSRHzG+1ujSi2IyNA65
RfTQJXJ0FHN/ytRg6acJSmqEydkvY3gxO8O16/eOyFJWFaH87KOlz3WzndhA73Vg
hG1Dffw5eP5+WaagV4pq23R126pXtG1/KVDzJn+KWezSJLuVHXstj1pBkN8P3aTR
8mHeN9KTovQ8Eu+jqafUVuDgdp9R1L6kZHZ8r2ePx/pUT2Yl59SPcNf3yGIdscqV
qg0uw0FXKh7TSgTO9+MvKqQwm9u8X5IAlbbT/KVeVVsZpr60Pu9tTJyVczdjivGq
CIdZVo//EhL2P1zz27wS5a+EuN1wC503e1wC32fBA2o8vc1KqGLsXXPj8RisMe4q
/pR+op+pF1073zZLQ8VhymCVf3xDBZmPHjjfcbV/AbcZm2AOVTRcILi88Gkad8QZ
i40ELnk4AtrzVAN/Yf5WZy3oDrqviv+XzrDtmxgIUjoe4JohivZK9nV2S3uFUCcx
Ks90cK0uoTIaBw38fyxR
=KsUJ
-----END PGP SIGNATURE-----
Reply to: