URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 94750
[ Назад ]

Исходное сообщение
"Критическая уязвимость в GnuTLS. Разработчик OpenLDAP рекоме..."

Отправлено opennews , 05-Мрт-14 11:51 
В GnuTLS 3.2.12 (http://gnutls.org/news.html), свободной библиотеке с реализацией протоколов SSL, TLS и DTLS и функций для работы с различными типами сертификатов, устранена критическая уязвимость (http://gnutls.org/security.html#GNUTLS-SA-2014-2) (CVE-2014-0092). Проблема проявляется во всех выпусках GnuTLS и даёт возможность обойти процедуры верификации сертификатов X.509, в результате чего специально оформленный поддельный сертификат может быть воспринят как валидный. Проблема выявлена сотрудниками Red Hat в результате аудита кода GnuTLS.


Злоумышленник, имеющий контроль над транзитным оборудованием (например, имеющий доступ к маршрутизатору или кабелю), может организовать MITM-атаку (man-in-the-middle) и использовать незаверенный в удостоверяющем центре поддельный сертификат для получения контроля над транзитным TLS-соединением клиента или для успешного прохождения аутентификации. Проблема возникла из-за  ошибочного выполнения команды очистки ('goto cleanup') без последующего перехода в секцию вывода ошибки  верификации ('goto fail'), что позволяет атакующему сформировать универсальный поддельный сертификат, который всегда будет проходить процедуру верификации.


Всем пользователям, использующим приложения, вызывающие функции  GnuTLS для организации аутентификации по сертификатам, следует срочно обновить GnuTLS.  На момент написания новости, пакеты с устранением уязвимости уже анонсированы  для Debian (https://www.debian.org/security/2014/dsa-2869), RHEL (http://rhn.redhat.com/errata/RHSA-2014-0247.html), Fedora (https://admin.fedoraproject.org/updates/), CentOS (http://lists.centos.org/pipermail/centos-announce/2014-March...), openSUSE (http://lists.opensuse.org/opensuse-security-announce/2014-03/), SLE, Ubuntu (https://lists.ubuntu.com/archives/ubuntu-security-announce/2...), FreeBSD (http://www.vuxml.org/freebsd/f645aa90-a3e8-11e3-a422-3c970e1...).


Уязвимость оценивается как очень серьёзная и подрывающая доверие к проекту.  Ховард Чу (Howard Chu), главный архитектор проекта OpenLDAP, ещё в 2008 году выступал (http://www.openldap.org/lists/openldap-devel/200802/msg00072...) с рекомендацией прекращения использования GnuTLS в связи с несоблюдением элементарных правил безопасности в кодовой базе GnuTLS, в частности, повсеместном использованим функций strlen и strcat. По мнению Ховарда, исправить ситуацию может только полный пересмотр API  GnuTLS.

URL: http://arstechnica.com/security/2014/03/critical-crypto-bug-...
Новость: http://www.opennet.me/opennews/art.shtml?num=39239


Содержание

Сообщения в этом обсуждении
"Критическая уязвимость в GnuTLS, позволяющая обойти процесс ..."
Отправлено Анонист , 05-Мрт-14 11:59 
С детства говорили - goto вреден для здоровья.

"Критическая уязвимость в GnuTLS, позволяющая обойти процесс ..."
Отправлено Аноним , 05-Мрт-14 12:15 
Это не более чем JMP в ассемблере, мальчик

"Критическая уязвимость в GnuTLS, позволяющая обойти процесс ..."
Отправлено анонимус , 05-Мрт-14 12:17 
Спасибо, капитан.

"Критическая уязвимость в GnuTLS, позволяющая обойти процесс ..."
Отправлено Аноним , 05-Мрт-14 12:22 
Может всё будем писать на ассемблере?

"Критическая уязвимость в GnuTLS, позволяющая обойти процесс ..."
Отправлено anonymous , 05-Мрт-14 14:50 
not sure if it's branch

"Критическая уязвимость в GnuTLS, позволяющая обойти процесс ..."
Отправлено metallica , 05-Мрт-14 15:17 
> Это не более чем JMP в ассемблере, мальчик

Вот jmp и есть плохо, наряду с всеми сравнительными jXX.


"Критическая уязвимость в GnuTLS, позволяющая обойти процесс ..."
Отправлено Маленькая Серая Мышка , 05-Мрт-14 17:33 
Чем же принципиально хуже JMP по сравнению с PUSH+JMP?

"Критическая уязвимость в GnuTLS, позволяющая обойти процесс ..."
Отправлено metallica , 05-Мрт-14 18:15 
> Чем же принципиально хуже JMP по сравнению с PUSH+JMP?

Ничем, за исключением продолжения декодирования процессором команд,
стоящих за call, и их исполнении после ret, что быстрее чем просто jmp.
Но вообще для критичных участков кода лучше использовать inline, в реализациях
STL они сплошь и рядом.



"Критическая уязвимость в GnuTLS, позволяющая обойти процесс ..."
Отправлено Маленькая Серая Мышка , 05-Мрт-14 20:45 
Инлайны не надо раставлять лет уже эдак 15 - любой приличный компилятор сам заинлайнит что можно.
А вот читать STL-ные сообщения об ошибках из-за этого совершенно невозможно.

"Критическая уязвимость в GnuTLS, позволяющая обойти..."
Отправлено arisu , 05-Мрт-14 18:50 
>> Это не более чем JMP в ассемблере, мальчик
> Вот jmp и есть плохо, наряду с всеми сравнительными jXX.

желаю тебе всю жизнь писать алгоритмы, где нужны циклы и условия, на языках, в которых нет циклов и условий.


"Критическая уязвимость в GnuTLS, позволяющая обойти процесс ..."
Отправлено Аноним , 07-Мрт-14 04:03 
> Вот jmp и есть плохо, наряду с всеми сравнительными jXX.

И правда, пользуйтесь SUBLEQ. Одной команды хватит всем!


"Критическая уязвимость в GnuTLS, позволяющая обойти процесс ..."
Отправлено Аноним , 05-Мрт-14 12:29 
goto здесь не при чём. Не было бы goto - был бы вызов неправильной функции.

"Критическая уязвимость в GnuTLS, позволяющая обойти процесс ..."
Отправлено Анонист , 05-Мрт-14 12:37 
Вызов неправильной функции легче отследить, не? Да и когда пишешь функцию минимум задумываешься о ее сигнатуре, о том, как ее назвать, и что конкретно она должна делать, (и это еще даже ДО любых рефакторингов) если это ООП и пишешь метод - думаешь еще о связности/сцеплении.

А goto - взял и написал goto. Очень много ума надо? Код на "от**бись*. Вполне подходит для мелкомягких, впрочем.


"Критическая уязвимость в GnuTLS, позволяющая обойти процесс ..."
Отправлено Аноним , 05-Мрт-14 12:46 
> Вызов неправильной функции легче отследить, не?

Не.

> Да и когда пишешь функцию минимум задумываешься о ее сигнатуре, о том, как ее назвать, и что конкретно она должна делать

Когда пишешь goto - думаешь как минимум как назвать метку и что должно происходить при переходе не неё. Сигнатуры тут никак не помогают ибо могут быть одинаковые.

> А goto - взял и написал goto. Очень много ума надо? Код на "от**бись*. Вполне подходит для мелкомягких, впрочем.

Для гнушников.


"Критическая уязвимость в GnuTLS, позволяющая обойти процесс ..."
Отправлено Анонист , 05-Мрт-14 13:01 
Да вы прямо-таки мастер написания меток! Это не вы сломали случаем? :)

Вы не убедите меня, что код с goto более или хотя бы равен по ответственности за написание функции или метода.

P.S. Поди, вы весь код в goto пишете, без функций, классов и методов? Идеальный код :)


"Критическая уязвимость в GnuTLS, позволяющая обойти процесс ..."
Отправлено rshadow , 05-Мрт-14 14:10 
именование это конечно повод для срача...

мне вот на ум приходит что для функции легче тест написать отдельный, а не простыню для теста одной функции делать


"Критическая уязвимость в GnuTLS, позволяющая обойти процесс ..."
Отправлено Аноним , 05-Мрт-14 14:29 
Тест можно написать для любого блока. Местные аналитики наслушавшиеся баек про goto is harmful даже не в курсе что goto от call отличается только помещением в стек адреса возврата.

"Критическая уязвимость в GnuTLS, позволяющая обойти процесс ..."
Отправлено Маленькая Серая Мышка , 05-Мрт-14 15:14 
А exceptions делаются на лонгджампе за минуту, да-да.
Как это отменяет тот факт что тестировать функцию удобней чем часть блока - неясно.

"Критическая уязвимость в GnuTLS, позволяющая обойти процесс ..."
Отправлено www2 , 05-Мрт-14 17:24 
Внезапно, блоки находятся внутри функции. А для каждой функции можно написать не один тест.

Кроме того, хороший тест выявляет неожиданное поведение функции, а не проверяет абстрактную правильность работы какого-то блока. Потому что по-хорошему тесты пишутся не исходя из кода, а исходя из требований. Лучше - если функцию и тесты реализуют вообще разные люди и без оглядки на существующую реализацию теста или функции соответственно.


"Критическая уязвимость в GnuTLS, позволяющая обойти процесс ..."
Отправлено Маленькая Серая Мышка , 05-Мрт-14 17:31 
>Внезапно, блоки находятся внутри функции. А для каждой функции можно написать не один тест.

А небо - синее. Речь шла про "удобней" а не "в принципе это возможно".

>хороший тест выявляет неожиданное поведение функции

Вспоминаем (в вашем случае - учим) комбинаторику. В функции N блоков, у каждого M граничных условий. Дальше рассказывать? Или вы на всем множестве аргументов предпочитаете тестировать за бесконечное время?


"Критическая уязвимость в GnuTLS, позволяющая обойти процесс ..."
Отправлено www2 , 07-Мрт-14 18:24 
> Вспоминаем (в вашем случае - учим) комбинаторику. В функции N блоков, у
> каждого M граничных условий. Дальше рассказывать? Или вы на всем множестве
> аргументов предпочитаете тестировать за бесконечное время?

Но часть блоков в определённых условиях не выполняется. Например, первое же условие завершает работу функции - все остальные не проверяются. Поэтому комбинаторику учи ты.

А ещё - прочитай то, что я написал выше. Тестировать нужно не N блоков, а проверять, что функция работает ожидаемым образом. Пусть там ещё 10 блоков с разными условиями добавятся, пусть несколько условий объединят в одно с одним блоком - проверять нужно правильность функции, а не её компонентов.


"Критическая уязвимость в GnuTLS, позволяющая обойти процесс ..."
Отправлено Аноним , 05-Мрт-14 18:00 
>Когда пишешь goto - думаешь как минимум как назвать метку

Долго и упорно думаешь... и называешь метки: m1, m2, m3,...
(Из опыта программирования на ассеблере для x86)


"Критическая уязвимость в GnuTLS, позволяющая обойти процесс ..."
Отправлено 1 , 05-Мрт-14 18:33 
А через три недели после сдачи кода выясняется, что нужна доработка. Открываешь код, видишь эти метки и думаешь "какого ***".

"Критическая уязвимость в GnuTLS, позволяющая обойти..."
Отправлено arisu , 05-Мрт-14 18:52 
> Долго и упорно думаешь... и называешь метки: m1, m2, m3,...
> (Из опыта программирования на ассеблере для x86)

нет, это из опыта быдлокодинга.


"Критическая уязвимость в GnuTLS, позволяющая обойти процесс ..."
Отправлено Аноним , 07-Мрт-14 04:05 
> (Из опыта программирования на ассеблере для x86)

О как, оказывается, быдлoкодить можно даже на асме.


"Критическая уязвимость в GnuTLS, позволяющая обойти процесс ..."
Отправлено ананим , 05-Мрт-14 13:16 
> С детства говорили - goto вреден для здоровья

Угу.
Когда жабу продвигали. Ну и вставляли зонд — жабаплагин. Со своей безопасностью,.. поэтессами.
Теперь вот не знают как закрыть.


"Критическая уязвимость в GnuTLS, позволяющая обойти процесс ..."
Отправлено Маленькая Серая Мышка , 05-Мрт-14 15:45 
Но ведь функции - еще хуже. Для них нужен стек, привет его переполнениям и прочим срывам.
А если функций не использовать - стек не нужен, безопасность повысилась.



"Критическая уязвимость в GnuTLS, позволяющая обойти процесс ..."
Отправлено тазовод , 06-Мрт-14 14:54 
С таким подходом только из стартапа в стартап прыгать. Первые коммиты в репозитарий. Те, кто идут за вами, как бы помягче сказать, не считают вас гениальным. Те, кому читать, дорабатывать, править ваш код.
И да, лечу по фотографии, удалённо, дорого.

"Критическая уязвимость в GnuTLS, позволяющая обойти процесс ..."
Отправлено тазовод , 06-Мрт-14 14:59 
> А если функций не использовать - стек не нужен, безопасность повысилась.

Сперва на ум приходит, что таких надо лечить. Долгая, скрупулёзная и тщательная многонедельная электрошоковая терапия электродами на гениталиях.  Но потом понимаешь, что это лишнее. Ведь умника, накатавшего в мейн() десяток меток, и заявляющего, что это мол для безопасности в реальности никогда не встретишь - ну не проходят они даже скромного испытательного срока. Никак невозможно.


"Критическая уязвимость в GnuTLS, позволяющая обойти процесс ..."
Отправлено rob pike , 06-Мрт-14 20:56 
Никакого main() - у нас ведь нет стека, забыли?
После процессинга аргументов командной строки делаем так:
; Now, calculate the page-size-aligned length from the end of .data to the top
; of the userspace addresses (See: http://en.wikipedia.org/wiki/X86-64)
mov rsi,0x00007fffffffffff
sub rsi,rdi
shr rsi,12
dec rsi
shl rsi,12
; Do the munmap() call. This unmaps the stack, which we no longer need.
syscall(sys_munmap,,)
; Fork away from calling TTY
syscall(sys_fork)

"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено wavedocs , 05-Мрт-14 12:23 
У меня так и не поднялась авторизация на с TLS, видать к лучшему

"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено Аноним , 05-Мрт-14 12:34 
Всегда говорил что GnuTLS - жалкая подделка под OpenSSL, переписанная только чтобы "GNU". Хорошо что у меня всё собрано с OpenSSL а не этой дрянью.

"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено Аноним , 07-Мрт-14 04:10 
> Всегда говорил что GnuTLS - жалкая подделка под OpenSSL, переписанная только чтобы
> "GNU". Хорошо что у меня всё собрано с OpenSSL а не этой дрянью.

Для начала, весь SSL/TLS - один большой кусок дряги.


"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено Аноним , 05-Мрт-14 12:40 
Позорный 'goto'

"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено Аноним , 05-Мрт-14 12:47 
> Позорный 'goto'

Позорные гнушные программисты. goto - всего лишь инструмент, если бы в проекте не использовался goto ошибка никуда не делась бы.


"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено Маленькая Серая Мышка , 05-Мрт-14 12:57 
ИЧСХ, совсем недавно в яблочной продукции была ровно та же фигня, только там был лишний goto fail; и отсутствие скобок в теле if.

"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено Аноним , 05-Мрт-14 12:59 
> ИЧСХ, совсем недавно в яблочной продукции была ровно та же фигня, только
> там был лишний goto fail; и отсутствие скобок в теле if.

ИЧСХ, "совсем недавно" мыли сотни багов, и с goto, и не с goto, и со скобками и без скоок.


"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено 123 , 05-Мрт-14 15:18 
Я дофига. Goto тяжко отлаживать и в крупных проектах очень матерям. Хотя тот-же case куда опаснее в неумелых руках.

"Критическая уязвимость в GnuTLS, существенно влияющая на..."
Отправлено arisu , 05-Мрт-14 18:54 
> Я дофига. Goto тяжко отлаживать и в крупных проектах очень матерям.

зачем же вы заставляете матерей отлаживать крупные проекты? наймите программистов уже.


"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено Аноним , 07-Мрт-14 04:11 
> Я дофига. Goto тяжко отлаживать и в крупных проектах очень матерям. Хотя
> тот-же case куда опаснее в неумелых руках.

Вы даже ваш спич на форуме отладить не можете. Куда уж вам крупные проекты отлаживать.


"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено Аноним , 05-Мрт-14 15:43 
нормальный программист легко обойдется без goto, на что не способен выросший на васике

"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено Маленькая Серая Мышка , 05-Мрт-14 16:32 
Машиной Тьюирнга он обойдется, сделанной из спичек и изоленты.

"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено Аноним , 07-Мрт-14 04:12 
> Машиной Тьюирнга он обойдется, сделанной из спичек и изоленты.

Может программмить виртуальный процессор понимающий subleq, это даже интереснее, пожалуй.


"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено www2 , 05-Мрт-14 17:33 
> нормальный программист легко обойдется без goto, на что не способен выросший на
> васике

Сравните два варианта кода:

if (error1)
{
  free(ptr1);
  free(ptr2);
  free_structure(stru);
  return ERROR;
}

... /* Много кода */

if (error2)
{
  free(ptr1);
  free(ptr2);
  free_structure(stru);
  return ERROR;
}

Или

if (error1)
  goto error;

... /* Много кода */

if (error2)
  goto error;

error:
  free(ptr1);
  free(ptr2);
  free_structure(stru);
  return ERROR;

Теперь нужно добавить ещё одну структуру, которую нужно очищать при выходе. Какова вероятность, что добавив освобождение этой структуры в условный блок error1 вы не забудете про условный блок error2 в первом случае? И какова вероятность того, что вы забудете это сделать во втором случае и не обнаружите этого?

Нормальный программист обойдётся. Только выбор не всегда очевиден, как это представляется на первый взгляд.


"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено Михаил , 06-Мрт-14 08:59 
нормальный в таком случае функцию error() сделает и будет ее вызывать.

"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено тоже Аноним , 06-Мрт-14 20:54 
Это С, напоминаю. Чтобы обработать локальные ptr1, ptr2, ..., их нужно будет в эту функцию передать. В результате вместо этого кода в столбик получаем практически то же самое в списке параметров. Забыть добавить что-то в обоих случаях сразу, конечно, будет сложнее.
Но логика получается в значительной степени неестественная.
Другое дело, что никто не мешает вынести этот блок в конец метода и все перед ним заключить в условия if(!error_happened) после первой же возможности ошибки. А поскольку выделенную память все равно нужно освободить, то и функцию желательно привести к единому выходу, перед которым это освобождение будет естественным образом происходить. Goto здесь разве что экономит память, которую придется потратить на флаги ошибок. Ну, и несколько лишних проверок тех флагов потребуются. Острой необходимости в goto нет.
Вообще if(condition) goto mark; ... mark: совершенно равнозначно if(!condition) { ... }

"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено www2 , 07-Мрт-14 18:26 
> нормальный в таком случае функцию error() сделает и будет ее вызывать.

Ага, на каждую функцию по функции error. error для error'а потом ещё написать.


"Критическая уязвимость в GnuTLS, существенно влияющая на..."
Отправлено arisu , 05-Мрт-14 18:55 
> нормальный программист легко обойдется без goto, на что не способен выросший на
> васике

это мы видели, да. вон, выше даже пример приведен, как «нормальные программисты обходятся без goto при помощи копипасты». зато гордятся, что «без goto».


"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено Ytch , 06-Мрт-14 00:16 
> нормальный программист легко обойдется без goto

Нормальный программист подумает головой и в каждом конкретном случае сможет принять аргументированное решение, когда целесообразно, а когда нет. В этом отличие от фанатиков, вырвавших фразу "goto - зло" из контекста и носящихся с ней как с аксиомой.


"Критическая уязвимость в GnuTLS. Разработчик OpenLDAP рекоме..."
Отправлено Маленькая Серая Мышка , 05-Мрт-14 13:05 
А теперь сравним время на решение этой проблемы - в корне, раз уж доверие подорвано, а не конкретной ошибки.

Gentoo:
echo "-gnutls" >> /etc/portage/make.conf
emerge --changed-use --deep @world

Остальные дистрибутивы:
N лет ждать и надеяться что мейнтейнеры вычистят gnutls, может быть, когда-нибудь


"Критическая уязвимость в GnuTLS. Разработчик OpenLDAP рекоме..."
Отправлено Аноним , 05-Мрт-14 13:14 
> А теперь сравним время на решение этой проблемы - в корне, раз
> уж доверие подорвано, а не конкретной ошибки.
> Gentoo:
> echo "-gnutls" >> /etc/portage/make.conf
> emerge --changed-use --deep @world

FreeBSD:
echo "OPTIONS_UNSET+=GNUTLS" >> /etc/make.conf
portmaster -af


"Критическая уязвимость в GnuTLS. Разработчик OpenLDAP рекоме..."
Отправлено karapuz2 , 05-Мрт-14 13:20 
А ничего, что у вас перестанет работать функциональность? # shutdown -P now есть на всех системах

"Критическая уязвимость в GnuTLS. Разработчик OpenLDAP рекоме..."
Отправлено rfc.1118 , 05-Мрт-14 13:23 
перестанет работать функциональность? что?

"Критическая уязвимость в GnuTLS. Разработчик OpenLDAP рекоме..."
Отправлено Аноним , 05-Мрт-14 13:24 
> А ничего, что у вас перестанет работать функциональность?

Это какая? SSL/TLS всю жизнь обеспечиваелся OpenSSL'ем, поэтому GnuTLS никакой функциональности не предоставляет, только дыры.

> # shutdown -P now есть на всех системах

Это к чему вообще?


"Критическая уязвимость в GnuTLS. Разработчик OpenLDAP рекоме..."
Отправлено karapuz2 , 05-Мрт-14 13:34 
> Это какая? SSL/TLS всю жизнь обеспечиваелся OpenSSL'ем, поэтому GnuTLS никакой функциональности
> не предоставляет

Ну раз gnutls не используетсЯ, о чем разговор то?

А если используется, то убирая gnutls - лишаемся его функциональности. При чем тут openssl? Про openssl другие новости будут.

> только дыры.

дыры. Но не только в gnutls. ( http://en.wikipedia.org/wiki/Openssl#Vulnerability_in_the_De... )


"Критическая уязвимость в GnuTLS. Разработчик OpenLDAP рекоме..."
Отправлено Маленькая Серая Мышка , 05-Мрт-14 13:50 
При том что при убирании флажка gnutls включается дефолтный флажок openssl.
Пересобираются автоматически пакеты, ранее использовавшие gnutls, чтобы далее они использовали openssl.
Никакой функциональности никто не лишается.

"Критическая уязвимость в GnuTLS. Разработчик OpenLDAP рекоме..."
Отправлено pavlinux , 05-Мрт-14 14:52 
> При том что при убирании флажка gnutls включается дефолтный флажок openssl.
> Пересобираются автоматически пакеты, ранее использовавшие gnutls, чтобы далее они использовали
> openssl.
> Никакой функциональности никто не лишается.

OpenSSL и GnuTLS частично совместимы на уровне функционала, но не на уровне API.


"Критическая уязвимость в GnuTLS. Разработчик OpenLDAP рекоме..."
Отправлено Маленькая Серая Мышка , 05-Мрт-14 15:12 
Поэтому некоторые пакеты и пересоберутся с --enable-openssl вместо gnutls.

"Критическая уязвимость в GnuTLS. Разработчик OpenLDAP рекоме..."
Отправлено pavlinux , 05-Мрт-14 15:19 
> Поэтому некоторые пакеты и пересоберутся с --enable-openssl вместо gnutls.

Пересоберутся, не значит будут работать как нужно.
Например в exim без GnuTLS не будет работать авторизация по SSMTP.

В общем, пока ты компиляешь, уже всё исправили и дыру закрыли.
И кстати, в OpenSSL дыр находят в разы больше. Компиляй обратно! :D


"Критическая уязвимость в GnuTLS. Разработчик OpenLDAP рекоме..."
Отправлено Маленькая Серая Мышка , 05-Мрт-14 15:41 
С чего бы им не работать как нужно?

Те, что завязаны только и конкретно на GnuTLS - не пересоберутся, о чем будет выведено на экран соответствующее сообщение от emerge (я не слишком подробно объясняю? но иначе тебе почему-то непонятно) и администратор будет решать проблему иным способом - например, озаботится сменой таких пакетов на аналогичные по функциональности, но к GnuTLS не привязанные. Но что-то таких не припоминается.

===
The first TLS support in Exim was implemented using OpenSSL. Support for GnuTLS followed later, when the first versions of GnuTLS were released. To build Exim to use GnuTLS, you need to set USE_GNUTLS=yes in Local/Makefile, in addition to SUPPORT_TLS=yes
===


"Критическая уязвимость в GnuTLS. Разработчик OpenLDAP рекоме..."
Отправлено Аноним , 05-Мрт-14 16:19 
> С чего бы им не работать как нужно?

Да потому что GnuTLS это не OpenSSL и на уровне API они несовместимы. Если две программы выполняют одинаковые задачи это еще не значит что на уровне API они будут идентичны.


"Критическая уязвимость в GnuTLS. Разработчик OpenLDAP рекоме..."
Отправлено Маленькая Серая Мышка , 05-Мрт-14 16:30 
Никто и не утверждал что на уровне API они совместимы. Поэтому в программах есть #ifdef OPENSSL и (опционально) #ifdef GNUTLS. А также соответствующие ключи сборки.

"Критическая уязвимость в GnuTLS. Разработчик OpenLDAP рекоме..."
Отправлено Аноним , 05-Мрт-14 17:26 
> Никто и не утверждал что на уровне API они совместимы. Поэтому в
> программах есть #ifdef OPENSSL и (опционально) #ifdef GNUTLS. А также соответствующие
> ключи сборки.

Да, это есть. Но это есть далеко не у всех, кто то поддерживает только openssl а кто то и то и другое. GNUtls не все поддерживают а вот openssl многие проекты. Но тут дело вкуса разработчика, по мне так надо делать возможность выбора.


"Критическая уязвимость в GnuTLS. Разработчик OpenLDAP рекоме..."
Отправлено pavlinux , 06-Мрт-14 18:33 
Я ему говорю как в реальности, а оно мне тут гугло кописату вставляет.
Там 90% не работает, без gnutls.

"Критическая уязвимость в GnuTLS. Разработчик OpenLDAP рекоме..."
Отправлено Маленькая Серая Мышка , 07-Мрт-14 22:02 
Если оно так, то это повод побыстрей с eximа слезть вне зависимости от gnutlsных дырок.

"Критическая уязвимость в GnuTLS. Разработчик OpenLDAP..."
Отправлено arisu , 05-Мрт-14 18:57 
> Поэтому некоторые пакеты и пересоберутся с --enable-openssl вместо gnutls.

особенно это поможет пакетам без поддержки OpenSSL.


"Критическая уязвимость в GnuTLS. Разработчик OpenLDAP..."
Отправлено Аноним , 05-Мрт-14 19:16 
>> Поэтому некоторые пакеты и пересоберутся с --enable-openssl вместо gnutls.
> особенно это поможет пакетам без поддержки OpenSSL.

А есть такие кто только на гнутом тлс-е? Ну хотябы парочка?


"Критическая уязвимость в GnuTLS. Разработчик OpenLDAP..."
Отправлено arisu , 05-Мрт-14 19:50 
> А есть такие кто только на гнутом тлс-е? Ну хотябы парочка?

эвон, выше в пример exim приводили — любимый MTA бебиановодов.


"Критическая уязвимость в GnuTLS. Разработчик OpenLDAP..."
Отправлено Аноним , 06-Мрт-14 02:09 
В генте почему-то можно выбрать, что использовать.

"Критическая уязвимость в GnuTLS. Разработчик OpenLDAP..."
Отправлено Аноним , 07-Мрт-14 11:50 
Ну так и в Debian никто не мешает тем же Postfix-ом пользоваться.

"Критическая уязвимость в GnuTLS. Разработчик OpenLDAP..."
Отправлено Аноним , 05-Мрт-14 20:05 
как минимум выше уже про exim сказали

"Критическая уязвимость в GnuTLS. Разработчик OpenLDAP..."
Отправлено rob pike , 06-Мрт-14 20:51 
Только неправду сказали.

"Критическая уязвимость в GnuTLS. Разработчик OpenLDAP рекоме..."
Отправлено Аноним , 07-Мрт-14 04:14 
> Это какая? SSL/TLS всю жизнь обеспечиваелся OpenSSL'ем, поэтому GnuTLS никакой
> функциональности не предоставляет, только дыры.

Если убрать маску лицмера с физиономии и поискать тут по новостям, в OpenSSL багов затыкали немеряно. Да и сам SSL/TLS - оставляет желать много лучшего.


"Критическая уязвимость в GnuTLS. Разработчик OpenLDAP рекоме..."
Отправлено rew , 05-Мрт-14 15:43 
ORLY?
[~]> shutdown -P now
shutdown: illegal option -- P
usage: shutdown [-] [-h | -p | -r | -k] [-o [-n]] time [warning-message ...]
       poweroff

"Критическая уязвимость в GnuTLS. Разработчик OpenLDAP рекоме..."
Отправлено Аноним , 07-Мрт-14 08:16 
Это от того, что shutdown был собран без поддержки GnuTLS.

"Критическая уязвимость в GnuTLS. Разработчик OpenLDAP рекоме..."
Отправлено Наивный чукотский юноша , 05-Мрт-14 13:23 
Остальные не истерят.

"Критическая уязвимость в GnuTLS. Разработчик OpenLDAP рекоме..."
Отправлено Аноним , 05-Мрт-14 13:24 
> Остальные не истерят.

Потому что давно ещё gnutls выпилили.


"Критическая уязвимость в GnuTLS. Разработчик OpenLDAP рекоме..."
Отправлено Andrey Mitrofanov , 05-Мрт-14 14:06 
> А теперь сравним время на решение этой проблемы
> Остальные дистрибутивы:
> N лет ждать и надеяться

"""На момент написания новости, пакеты с устранением уязвимости уже анонсированы для Debian, RHEL, Fedora, CentOS, openSUSE, SLE, Ubuntu, FreeBSD.

Время решения: вчера. Сравнивай.


"Критическая уязвимость в GnuTLS. Разработчик OpenLDAP рекоме..."
Отправлено Маленькая Серая Мышка , 05-Мрт-14 14:29 
>>в корне, раз уж доверие подорвано, а не конкретной ошибки

Учу читать, дорого.


"Критическая уязвимость в GnuTLS. Разработчик OpenLDAP рекоме..."
Отправлено Аноним , 05-Мрт-14 18:53 
>>>в корне, раз уж доверие подорвано, а не конкретной ошибки
> Учу читать, дорого.

Ядро Linux неоднократно "подрывало доверие к себе", и ничего.
Наверное, потому что мир состоит не только из белок-истеричек.


"Критическая уязвимость в GnuTLS. Разработчик OpenLDAP рекоме..."
Отправлено pavlinux , 05-Мрт-14 14:12 
> Остальные дистрибутивы:
> N лет ждать и надеяться что мейнтейнеры вычистят gnutls, может быть, когда-нибудь

Это конечно же, почтовый, корпоративный или HA сервер, с тысячами юзеров и терабайтом трафика?


"Критическая уязвимость в GnuTLS. Разработчик OpenLDAP рекоме..."
Отправлено Аноним , 05-Мрт-14 18:24 
>echo "-gnutls" >> /etc/portage/make.conf
>emerge --changed-use --deep @world

Зачем?
Новый ebuild с устранением уязвимости не заставит себя ждать. И останется только
emerge --update @world


"Критическая уязвимость в GnuTLS. Разработчик OpenLDAP рекоме..."
Отправлено Michael Shigorin , 05-Мрт-14 22:03 
> А теперь сравним время на решение этой проблемы - в корне

...и дальше пример на конкретный апстрим, замечательно.  Так и я могу сказать, что на локалхосте с сизифом об libgnutls26 прямщас были зацеплены e17 с connman, gnustep, qemu и vlc-plugin-gnutls -- мол, ничего страшного вообще (с учётом того, что последний уже и удалил)...


"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено Аноним , 05-Мрт-14 13:18 
А в чём проблема в "повсеместном использованим функций strlen и strcat"?
// опечатка, кстати

"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено Аноним , 05-Мрт-14 13:21 
> А в чём проблема в "повсеместном использованим функций strlen и strcat"?

В strlen проблем нет, а strcpy/strcat не ограничивают длину буфера куда пишут, поэтому могут его переполнить.


"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено клоун Стаканчик , 05-Мрт-14 13:33 
> В strlen проблем нет

Если строка не нуль-терминирована (получена из внешнего источника), то при использовании strlen можно выйти за предел буфера. Иногда подобная ошибка возникает как следствие ухода от другой ошибки: в буфер пишут не больше размера буфера, но не дописывают финальный "\0".

Также ошибка может возникнуть при обращении к неиницилизированной строке (выделили память, вызвали strlen).


"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено pavlinux , 07-Мрт-14 03:35 
>> В strlen проблем нет
> Если строка не нуль-терминирована (получена из внешнего источника), то при использовании
> strlen можно выйти за предел буфера.

Какого буфера, чо ты гонишь!  


size_t strlen(const char *s)
{
    const char *c;
      for (c = s; *c != '\0'; ++c);
  return c - s;
}

И надо очень хорошо постараться, чтоб функции идущие до strlen не глюкнули от того,
что ты хочешь запихнуть в strlen. Например строку длиной в 16 эксабайт.  

> Также ошибка может возникнуть при обращении к неиницилизированной строке (выделили память, вызвали strlen).

Талант,... книжке случайно не пишешь? Так вот, не пиши! А то, может-не может, если, да вдруг...  

Уже неделю сижу, жду ошипке


void main(void) {

   while(1)
       strlen((const char *)malloc(1000));
}



"Критическая уязвимость в GnuTLS, существенно влияющая на..."
Отправлено arisu , 05-Мрт-14 18:59 
> оттуда же
> В стандартах программирования GNU нет ни слова про написание безопасного кода.

потому что они писались программистами для программистов. а потом, к сожалению, пришли быдлокодеры, которым если явно не скажешь задницу после сортира вытирать/мыть, так они и не станут.


"Критическая уязвимость в GnuTLS, существенно влияющая на..."
Отправлено Аноним , 07-Мрт-14 04:16 
> быдлoкодеры, которым если явно не скажешь задницу после сортира вытирать/мыть, так
> они и не станут.

Еще и сделают удивленную рожу - "у тебя что, майка короткая?!" (c) анекдот.


"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено Аноним , 05-Мрт-14 13:50 
"tls-server" в openvpn его использует?
Обновы не видно что-то...

"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено pavlinux , 05-Мрт-14 14:35 
Оно, не?! http://www.opennet.me/openforum/vsluhforumID1/95435.html

"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено Аноним , 05-Мрт-14 14:58 
У меня déjà vu

"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено Аноним , 05-Мрт-14 15:05 
У Яблочников ведь такое же было, нет?

"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено metallica , 05-Мрт-14 15:20 
Вместо goto A используется goto B.
Мне одному мерещится умысел, а не баг?

"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено Grisha76 , 05-Мрт-14 18:13 
> Предпочтение GnuTLS вместо OpenSSL по лицензионным соображениям в Ubuntu и Debian также приводит к привязке к GnuTLS и других важных пакетов, таких как VPN-приложения и SSL-модули Nginx

Какой бред! Автор сам придумал? Nginx не умеет работать с GnuTLS и крепко завязан на функциональность OpenSSL.


"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено iZEN , 05-Мрт-14 19:49 
% pkg info -x tls
gnutls-2.12.23_3

% pkg info -r gnutls-2.12.23_3
gnutls-2.12.23_3:
    glib-networking-2.36.2

% pkg info -r glib-networking-2.36.2
glib-networking-2.36.2:
    libsoup-2.40.3_2
    libsoup-gnome-2.40.3_3

% pkg info -r libsoup-2.40.3_2
libsoup-2.40.3_2:
    libsoup-gnome-2.40.3_3
    gvfs-1.12.3_2
    gedit-2.30.4_2
    gstreamer-plugins-soup-0.10.31,3
    libchamplain-0.8.1_3
    libgdata-0.6.6_1
    totem-pl-parser-2.32.3_2
    eog-plugins-2.30.1_5
    totem-2.32.0_2
    xfce4-screenshooter-plugin-1.8.1_4
    webkit-gtk2-1.8.3_3
    yelp-2.30.2_7
    midori-0.5.7


"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено IMHO , 05-Мрт-14 20:55 
мне жить уже страшно с FreeBSD
)))))

"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено Аноним , 06-Мрт-14 02:15 
1. Сделай то же самое в бебиане - тебя вообще удар хватит.
2. Бинарнота, фуле ж.

"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено pavel_simple , 06-Мрт-14 05:02 
> 1. Сделай то же самое в бебиане - тебя вообще удар хватит.
> 2. Бинарнота, фуле ж.

    --- libc6 (>= 2.8)
    --- libgcrypt11 (>= 1.4.5)
    --- libp11-kit0 (>= 0.11)
    --- libtasn1-3 (>= 1.6-0)
    --- zlib1g (>= 1:1.1.4)
    --- libgpg-error0 (>= 1.10)

умойся


"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено Аноним , 06-Мрт-14 10:33 
Нет, ты. Это зависимости gnutls, а надо обратные зависимости (т.е. те пакеты, которые зависят от gnutls).

"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено pavel_simple , 06-Мрт-14 10:48 
> Нет, ты.

нет что?


"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено Аноним , 05-Мрт-14 21:26 
Что ты сделал с системой, криворукий, что pkg у тебя для gnutls не показывает всё что она показывает для libsoup?

"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено iZEN , 05-Мрт-14 21:51 
> Что ты сделал с системой, криворукий, что pkg у тебя для gnutls
> не показывает всё что она показывает для libsoup?

Вопрос к разработчикам pkgng. pkg_info(1) в предыдущей версии системы показывала ВСЕ зависимости.


"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено Аноним , 06-Мрт-14 15:32 
Вопрос к твоим кривым рукам. У меня pkg показывает ВСЕ зависимости.

"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено iZEN , 06-Мрт-14 20:54 
Выложи. Оценим.

"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено Аноним , 07-Мрт-14 04:19 
> Вопрос к разработчикам pkgng.

Ну это обычная бсдшная стабильность и протестированность кода, походу. ZFS вон тоже релизнули стабильным. С стабильно виснущим sendfile().


"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено iZEN , 07-Мрт-14 20:49 
>> Вопрос к разработчикам pkgng.
> Ну это обычная бсдшная стабильность и протестированность кода, походу. ZFS вон тоже
> релизнули стабильным. С стабильно виснущим sendfile().

Сюрпризов со стабилностью в Ext4 тоже хватает:
1. http://www.linux.org.ru/forum/desktop/10258156
2. http://www.linux.org.ru/forum/admin/10259434


"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено Маленькая Серая Мышка , 07-Мрт-14 22:36 
Совершенно не факт что ext4 там при чём-то.

"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено iZEN , 07-Мрт-14 23:09 
> Совершенно не факт что ext4 там при чём-то.

Отчего же не факт? Факты говорят, что ФС не справляется с очевидными ошибками и не может даже диагностировать потерю данных!



"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено Маленькая Серая Мышка , 08-Мрт-14 16:51 
А ничего что FS там не напрямую с диском работает? Есть еще LVM, md, драйвера, ядро в целом, фирмварь дисков. На каком основании вы утверждаете что проблема именно в FS?

"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено AlexAT , 07-Мрт-14 22:53 
> Сюрпризов со стабилностью в Ext4 тоже хватает:

А давай мы не будем заново заквашивать, а? Всё уже неоднократно насчет ZFS vs * разобрали по полочкам, и сделали выводы.


"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено iZEN , 07-Мрт-14 23:08 
>> Сюрпризов со стабилностью в Ext4 тоже хватает:
> А давай мы не будем заново заквашивать, а? Всё уже неоднократно насчет
> ZFS vs * разобрали по полочкам, и сделали выводы.

Вот только почему-то выводы делают те, кто ZFS только по скриншотам консоли видел и/или слышал отзывы о работе как по испорченному телефону, заминая очевидные причины. ;)



"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено Маленькая Серая Мышка , 08-Мрт-14 16:53 
Те кто _действительно_ давно и глубоко знает ZFS, например Brendan Gregg, далеко не так категоричны в отстаивании её преимуществ.

"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено Пиу , 06-Мрт-14 01:51 
этим чудакам уже показали юнит-тестирование?

"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено Andrey Mitrofanov , 06-Мрт-14 09:52 
> этим чудакам уже показали юнит-тестирование?

Да, целая выставка, конечно: openssl, nss, gnupg. Мильёны и мильярды их. И все _показывают, как надо тестировать.


"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено Аноним , 06-Мрт-14 08:04 
Всмысле, опять все старые дистрибуитвы Linux на свалку?
Каждый месяц в мире Linux происходит очередной Апокалипсис :(
Я уже задумываюсь, а не поставить ли мне на сервер вместо линушки - Haiku.
В ней-то уж точно всё стабильно, с самого её появления.

"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено AlexAT , 06-Мрт-14 08:59 
Я бы рекомендовал MS-DOS 6.22.

"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено Аноним , 06-Мрт-14 10:34 
> Я уже задумываюсь, а не поставить ли мне на сервер вместо линушки
> - Haiku.
> В ней-то уж точно всё стабильно, с самого её появления.

Админ локалхоста? Тогда ставь, конечно, че уж.


"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено metallica , 06-Мрт-14 11:10 

> Админ локалхоста? Тогда ставь, конечно, че уж.

Нет, господа, для задачек, как то хостинг фоток котят и подружек, линукс можете смело
использовать, а вот для чего поважней его всё равно никто не использует.
Что? Гуглы/фейсбуки? Вот там линуксы перепиленные вдоль и поперёк, и  имеют много
различий с теми массовыми всеми любимыми бабуинианами.
На одном форуме читал откровения разраба из ЖЖ, который рассказывал как с стартовой
конфигурации ввиде debian+mysql+apache долгим и упорным допиливанием получали
пригодную конфигурацию.


"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено Аноним , 07-Мрт-14 04:24 
> Что? Гуглы/фейсбуки? Вот там линуксы перепиленные вдоль и поперёк, и  имеют
> много различий с теми массовыми всеми любимыми бабуинианами.

Ну, крутой хакер, иди, полАмай википедию чтоли для начала. А то там вообще убунта какая-то, понимаешь.

> конфигурации ввиде debian+mysql+apache долгим и упорным допиливанием получали
> пригодную конфигурацию.

А ты сам подними инфраструктуру размером с ЖЖ хоть там на чем, я посмотрю как ты без напильника обойдешься. Без напильника получаются только типовые задачи. Сервис обслуживающий всю планету таковым не является.


"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено Аноним , 07-Мрт-14 04:21 
> В ней-то уж точно всё стабильно, с самого её появления.

Да, в ней такой стабилизец, что там до сих пор помнят такой артефакт как GCC 2.95 и даже по слухам пользуются им. Для обеспечения совместимости ABI с какой-то доисторической проприетарью, которую никто никогда не увидит и уж тем более при всем желании не купит легально в 2014 году.


"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено Васька , 07-Мрт-14 19:26 
> Злоумышленник, имеющий контроль над транзитным оборудованием (например, имеющий доступ к маршрутизатору или кабелю), может организовать MITM-атаку (man-in-the-middle) и использовать незаверенный в удостоверяющем центре поддельный сертификат для получения контроля над транзитным TLS-соединением клиента.

М, как интересно. То есть если сертификат заверен с сертифицируещем центре дает возможность пасти защищенное таким вот методом соединение? Или я чего то недопонимаю? Прелестно, Прелестно !


"Критическая уязвимость в GnuTLS, существенно влияющая на без..."
Отправлено тоже Аноним , 07-Мрт-14 22:35 
Вы недопонимаете, что антивирусы, например, делают это далеко не первый год.