Re: [DONE] wml://{security/2015/dla-192.wml}
On Tue, May 31, 2016 at 11:59:29AM +0500, Lev Lamberov wrote:
> -----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 в
"NTP-сервера" (с дефисом) или "сервера 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,
вообще "peer" - это "равный партнёр", то есть, когда связываются,
например, два узла по протоколу "точка-к-точке" ("peer-to-peer"),
поэтому здесь я бы перевёл как "соединяются друг с другом
(симметричная связь)..."
> + что приведёт к установке переменных состояния 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>
лишь из
Reply to: