15.05.2008

Доверяй но проверяй! А лучше пересчитай…

13 мая 2008 года проект Debian известил своих пользователей о вышедшем исправлении, затрагивающем генерацию случайных чисел в библиотеке OpenSSL, поставляемой в составе операционной системы Debian Linux.

Как уже догадались многие читатели, речь в этой заметке пойдет о недавно обнаруженной уязвимости в генераторе случайных чисел в OpenSSL в Debian Linux и производных системах (Ubuntu, Kubuntu и т.д.).

А что же произошло?

13 мая 2008 года проект Debian известил своих пользователей о вышедшем исправлении, затрагивающем генерацию случайных чисел в библиотеке OpenSSL, поставляемой в составе операционной системы Debian Linux. Ошибка состояла в том, что следующие строки были удалены из файла md_rand.c:

MD_Update(&m,buf,j);
[ .. ]
MD_Update(&m,buf,j); /* purify complains */

Эти строки были удалены из-за того, что утилиты Valgrind и Purify сообщали об использовании неинициализированных данных в любом коде, который использовал OpenSSL (пример подобного сообщения). Удаление этих строк привело к тому, что в качестве случайного числа стал использоваться только идентификатор текущего процесса (на Linux системах, максимальный идентификатор процесса равен 32768).

И какие последствия?

Все SSL и SSH ключи, сгенерированные на производных от Debian системах с сентября 2006 по 13 мая 2008 являются слабыми с криптографической точки зрения. Это означает, что злоумышленник может воссоздать ключ и с его помощью подписать новые сертификаты. Злоумышленник может таким образом произвести брут-форс атаку на SSH сервер, полагающийся на публичные колючи при аутентификации, Web сервер, аутентифицирующий пользователей по персональным сертификатам и другие службы. Также, открывается пространство для атаки типа «Человек по средние» и расшифровке перехваченного зашифрованного трафика.

А сложна ли эксплуатация уязвимости?

Сложность эксплуатации зависит от используемого алгоритма. H.D. Moore опубликовал на сайте metasploit.com пример реализации атак и приблизительное время, требуемое для эксплуатации в зависимости от алгоритма.

На сайте SecurityLab доступен PoC код.

Что же делать?

Всем пользователям рекомендуется установить исправление, доступное на сайте производителя и пересоздать все ранее сгенерированные ключи. Уязвимость усугубляется тем, что сертификаты, подписанные подобным ключем, могут использоваться на различных системах. Поэтому, если вы не уверены, на какой системе был сгенерирован ключ, которым подписаны ваши сертификаты, рекомендуем вам сгенерировать новый ключ.

Валерий Марчук,
www.SecurityLab.ru

или введите имя

CAPTCHA
Страницы: 1  2  3  
1
15-05-2008 22:19:23
Баян, но зато собрана вся информация и написано достаточно внятно.
0 |
1
15-05-2008 23:59:01
точно инфа собрана грамотно,
0 |
19-05-2008 05:59:27
-1 афтар перевёл часть (начало) статьи http://metasploit.com/users/hdm/tools/debian-openssl/
0 |
19-05-2008 09:08:19
угу, а еще в статье есть ссылка на метасплойт (указанный вами адрес)
0 |
16-05-2008 00:53:29
Полезная статья
0 |
1
16-05-2008 05:34:36
Не удалены, а закомментированы. Всё равно человеческий фактор, ведь автоматика это лишь автоматика... А вот решение принимал человек. Хотя, лично я думал, что просто кто-то не выспался
0 |
1
16-05-2008 06:19:22
Облажались так облажались. Автора изменений - в банлист пока не начнет думать и следовать принципу "семь раз отмерь один раз отрежь". PS Картинку зачотная. )
0 |
1
16-05-2008 06:29:49
на Linux системах, максимальный идентификатор процесса равен 32768Неточность. На 32-битных системах, видимо, так и есть(хотя ядерное pid_t определено как 32-битное значение, т.е. теоретический потолок около 4 млрд.: typedef int __kernel_pid_t;), а на 64-разрядных максимальное число процессов может быть и больше 32768: $ uname -r 2.6.18-4-amd64 $ /sbin/sysctl -a|grep pid error: "Success" reading key "dev.parport.parport0.autoprobe3" error: "Success" reading key "dev.parport.parport0.autoprobe2" error: "Success" reading key "dev.parport.parport0.autoprobe1" error: "Success" reading key "dev.parport.parport0.autoprobe0" error: "Success" reading key "dev.parport.parport0.autoprobe" error: permission denied on key 'net.ipv6.route.flush' error: permission denied on key 'net.ipv4.route.flush' error: permission denied on key 'kernel.cad_pid' error: permission denied on key 'kernel.cap-bound' kernel.pid_max = 32768 kernel.core_uses_pid = 0 $ sudo /sbin/sysctl kernel.pid_max=256000 kernel.pid_max = 256000 $ /sbin/sysctl kernel.pid_max kernel.pid_max = 256000
0 |
1
16-05-2008 11:24:03
на 32-битных системах точно так же меняется pid_max (у меня, например, на двух нагруженных серверах приложений выставлен в 100000).
0 |
1
16-05-2008 12:36:42
# sysctl kernel.pid_max=32768 kernel.pid_max = 32768 # sysctl kernel.pid_max=32769 error: "Invalid argument" setting key "kernel.pid_max" # sysctl kernel.pid_max=65536 error: "Invalid argument" setting key "kernel.pid_max" # uname -r 2.6.18-5-686
0 |
Страницы: 1  2  3