LINUX.ORG.RU

Критическая уязвимость в libgcrypt 1.9.0

 , , , ,


0

1

28 января была обнаружена 0-day уязвимость в криптографической библиотеке libgcrypt неким Tavis Ormandy из Project Zero (группа специалистов безопасности в Google, которые ищут 0-day уязвимости).

Уязвимости подвержена только версия 1.9.0 (ныне переименованная на апстримном ftp-сервере, чтобы избежать случайного скачивания). Из-за неверных предположений в коде возможно переполнение буфера, потенциально приводящее к удалённому выполнению кода. Переполнение может произойти в ходе расшифровки данных до этапа верификации и проверки подписи, что упрощает эксплуатацию.

Версия 1.9.1 с исправлением была выпущена на следующий день после сообщения об уязвимости. Баг появился в результате неудачной оптимизации функции записи хеша почти 2 года назад.

>>> Подробности

Почему то вспоминается Неуловимый Джо)

anonymous ()

0-day уязвимость в результате неудачной оптимизации почти 2 года назад. А как же миллионы глаз? Где они были все эти два года?

hummer ()

неким Tavis Ormandy

поржал

s-o ()
Ответ на: комментарий от TeopeTuK

Ты так говоришь, как будто до 19 января этот код был почти два года заперт на ключ и никто не мог его изучать. Где был Эрик Реймонд с его базарной моделью разработки?

hummer ()
Ответ на: комментарий от WindowsXP

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

hummer ()
Ответ на: комментарий от hummer

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

Thero ★★★★★ ()

а я еще удивился, чего это в генте так быстро откатили на 1.8.6.

leg0las ★★★★★ ()

Серьезная уязвимость, которой еще не присвоили CVE

Antonova ()
Ответ на: комментарий от Thero

Закрытые обновления Windows прекрасно преодолевают любых манагеров. То есть не в противопоставлении открытого кода закрытому дело, а в таком явлении как нечитабельный код. Чем более нечитабелен код тем дольше проблемы в нём не замечают.

hummer ()

ихний код сатана писал что ли. неудивительно что там уязвимость образовалась.

salozar ()

‘_gcry_md_block_write’ did not expect ‘hd->count’ being greater than digest blocksize. However digest final function may set ‘hd->count’ to larger value.

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

salozar ()
Ответ на: комментарий от hummer

как ооп поможет против дебила, который гадит в переменные? хеш 32 байта но напишу-ка я в длину 40 потому что «мы здесь власть».

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

salozar ()
Ответ на: комментарий от salozar

как ооп поможет против дебила, который гадит в переменные? хеш 32 байта но напишу-ка я в длину 40 потому что «мы здесь власть».

Я же выше написал - инкапсуляция. В нормальном ООП у тебя нет прямого доступа к полям класса. Твои ассерты - это фактически попытка реализовать инкапсуляцию костылями.

hummer ()

https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=blobdiff;f=cipher/hash-common.c;h=74675d49fe48099af2ea34c1243936a1c7ab5c33;hp=a750d6443d082dfccc3cc2c875f724b1592444d5;hb=e76617cbab018dd8f41fd6b4ec6740b5303f7e13;hpb=f8d14df1abd645c3279b14da43b4a7983d87f89f

Такой априори байтобуфернокопательный код можно было и отревьюить и протестировать как следует. Похоже на подход «commit earlier, get hacked earlier», вполне по-опенсорски.

seiken ★★★★★ ()
Ответ на: комментарий от hummer

почти 2 года назад. А как же миллионы глаз? Где они были все эти два года?

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

seiken ★★★★★ ()
Ответ на: комментарий от seiken

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

salozar ()
Ответ на: комментарий от thunar

С-культура же.

Ну да, привет из 70-х. А что с этим делать?

hummer ()
Ответ на: комментарий от seiken

Такой априори байтобуфернокопательный код можно было и отревьюить и протестировать как следует. Похоже на подход «commit earlier, get hacked earlier», вполне по-опенсорски.

Ну вот смотрю я на это:

  if (inlen)
    {
      buf_cpy (hd->buf, inbuf, inlen);
      hd->count = inlen;
    }

и не понимаю, почему в 2021 году это ещё не переписали на ООП языке и заодно не перевели на нормальное именование переменных. Что такое hd и почему я должен долго лазить по коду, чтобы это узнать? Почему этот hd не является объектом со своей собственной реализацией копирования буфера и соответствующими проверками выхода за его границы? Почему в критически важном софте продолжают использовать примитивные технологии 70-х годов?

hummer ()
Ответ на: комментарий от hummer

и не понимаю, почему в 2021 году это ещё не переписали на ООП языке

кто это будет оплачивать? Вот ты, если такой прогрессивный, почему не возьмешь, и не перепишешь? И потом, почему ты думаешь, что от того, что перепишут на ООП ЯП подобные проблемы исчезнут. На том же C++ можно наколбасить, во-первых, в анти-ООП стиле, и во-вторых, со всеми теми же проблемами с памятью, и получится еще более сложный для анализа код.

и заодно не перевели на нормальное именование переменных. Что такое hd и почему я должен долго лазить по коду, чтобы это узнать?

это «заодно» никак не зависит от используемого ЯП. И на ООП языке можно тоже использовать схемы именования «из 70х». К тому же, найдутся критики из другого лагеря: что за MyVerySelfexplanatoryVariableName? кто пустил дурачков жабистов в наш код?

Почему в критически важном софте продолжают использовать примитивные технологии 70-х годов?

в смысле ООП, думаю все просто: в таком низкоуровневом и околосистемном коде (в отличие от более разнообразного мира прикладного ПО) количество сущностей ограничено, все они по-технарски специфические, давно изучены, и соотв. абстракции давно уже существуют в терминах простого процедурного ЯП. Введение новых абстракций ООП не даст таких преимуществ, как в прикладном софте, в котором сущности из очень разных предметных областей, и многие есть модель реальных сущностей за пределами IT.

Зато появится дополнительная зависимость: еще один компилятор (даже если это только фронтенд), еще больше сложности в поддержке и портировании. И дополнительные телодвижения ради обеспечения совместимости с кодом на C, даже если эти телодвижения минимальны среди всех остальных ЯП.

А преимущества где?

seiken ★★★★★ ()
Последнее исправление: seiken (всего исправлений: 1)

Критическая уязвимость в libgcrypt 1.9.0

 % pkg query '%v' libgcrypt
1.8.7

Я спокоен. :3

mord0d ★★★★ ()
Ответ на: комментарий от seiken

кто это будет оплачивать?

А кто оплачивает этот говнокод и ущерб от его дырявости?

Вот ты, если такой прогрессивный, почему не возьмешь, и не перепишешь?

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

И потом, почему ты думаешь, что от того, что перепишут на ООП ЯП подобные проблемы исчезнут. На том же C++ можно наколбасить, во-первых, в анти-ООП стиле, и во-вторых, со всеми теми же проблемами с памятью, и получится еще более сложный для анализа код.

Да, C++ неидеален, мультипарадигменен и позволяет отстрелить себе ногу вмести с туловищем, при очень большом желании. Однако, в отличии от чистого C, он всё таки поддерживает ООП. И при соблюдении довольно простой самодисциплины позволяет писать гораздо более качественный и безопасный код, чем на чистом C. Так же можно рассмотреть альтернативы или даже создать новый язык программирования. Тот же язык C появился не сам по себе, а в ходе создания UNIX и на основе BCPL.

в смысле ООП, думаю все просто: в таком низкоуровневом и околосистемном коде (в отличие от более разнообразного мира прикладного ПО) количество сущностей ограничено, все они по-технарски специфические, давно изучены, и соотв. абстракции давно уже существуют в терминах простого процедурного ЯП. Введение новых абстракций ООП не даст таких преимуществ, как в прикладном софте, в котором сущности из очень разных предметных областей, и многие есть модель реальных сущностей за пределами IT.

Это подход поддержания работоспособности застывшего говна мамонта и это совершенно непрофессиональный подход. Всякий раз, когда всё таки приходится что-то в нём менять, вероятность что-то сломать весьма высока и сложность это предотвратить тоже. Так же происходит смена поколений программистов и желающих влезать в эту C-культуру 70-х и 80-х всё меньше и меньше. Примерно то же самое произошло с языком COBOL и с большим количеством кода, который на нём написан. Этим кодом сейчас занимаются практически одни лишь пенсионеры и от него всячески стараются избавиться.

Зато появится дополнительная зависимость: еще один компилятор (даже если это только фронтенд), еще больше сложности в поддержке и портировании. И дополнительные телодвижения ради обеспечения совместимости с кодом на C, даже если эти телодвижения минимальны среди всех остальных ЯП.

В случае C++ это всё тот же компилятор.

hummer ()
Ответ на: комментарий от hummer

Почему этот hd не является объектом со своей собственной реализацией копирования буфера и соответствующими проверками выхода за его границы? Почему в критически важном софте продолжают использовать примитивные технологии 70-х годов?

а чем инкапсуляция в объект лучше инкапсуляции в, скажем, функцию? почему проверки выхода за границы не сделать на входе функции? почему нельзя написать собственную реализацию копирования буфера для hd просто как отдельную функцию?

Почему в критически важном софте продолжают использовать примитивные технологии 70-х годов?

А чем плохи технологии 70-х? Может потому и используют, что не плохи? Молоток – каких лет технология, а, поди ж ты, в космосе используют по сей день

pihter ★★★★ ()
Ответ на: комментарий от seiken

почему ты думаешь, что от того, что перепишут на ООП ЯП подобные проблемы исчезнут. На том же C++ можно наколбасить, во-первых, в анти-ООП стиле, и во-вторых, со всеми теми же проблемами с памятью, и получится еще более сложный для анализа код.

мне всю жизнь эта мысль в голову лезет. От этих ваших плюсов ничего не исправляется, только расковырыватиь сложнее

pihter ★★★★ ()
Ответ на: комментарий от hummer

И при соблюдении довольно простой самодисциплины позволяет писать гораздо более качественный и безопасный код, чем на чистом C

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

pihter ★★★★ ()
Ответ на: комментарий от hummer

А кто оплачивает этот говнокод и ущерб от его дырявости?

ну тут же не много вариантов. Либо кто-то пилит for fun, либо пилит по заданию работодателя, либо пилит без явного работодателя, но за грант.

В первом случае, какие могут быть претензии к for fun?

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

А я что, против? Критикуй на здоровье, я просто об’ясняю, почему оно сложилось так, а не иначе, на что есть об’ективные причины. Со вселенной ты передергиваешь. libcrypt всего лишь библиотека, созданная целесообразными инструментами. Были бы другие требования, были бы и другие инструменты. Например, в вендовом мире взяли бы какой-нибудь C# или managed C++.

Да, C++ неидеален, мультипарадигменен и позволяет отстрелить себе ногу вмести с туловищем, при очень большом желании. Однако, в отличии от чистого C, он всё таки поддерживает ООП. И при соблюдении довольно простой самодисциплины позволяет писать гораздо более качественный и безопасный код, чем на чистом C.

Здесь несколько условий, которые нужно соблюсти, прежде чем получить преимущества от использования C++. Самое главное - автору следует знать C++. А может быть, он его знает на уровне хелловорлдов. Тогда чем его плюсовый код будет отличаться от сишного? И тогда никакого «гораздо более качественный и безопасный» не будет.

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

O-o, пошла тяжелая пионерия. libcrypt существует и работает, хоть иногда и бажно. А ты предлагаешь ее переписать на каком-то самодельном ЯП, еще больше сужая круг могущих и желающих помочь проекту?

Тот же язык C появился не сам по себе, а в ходе создания UNIX и на основе BCPL.

Это мы сейчас постфактум рассуждаем, как это было круто, и какие молодцы авторы C. А тогда, в начале 70х не было известно, взлетит ли UNIX или нет. Не взлетел бы, и о нем знали бы только историки. Новый ЯП может стать революционным, но это не значит, что новый ЯП сам по себе достаточное условие для возникновения революции. А в данном случае у нас даже не эпохальная ОС, а только криптографическая библиотека.

Всякий раз, когда всё таки приходится что-то в нём менять, вероятность что-то сломать весьма высока и сложность это предотвратить тоже.

Не все системы одинаково простые, да. В случае с libcrypt не доказано, что переход на другой ЯП позволит более эффективно контролировать сложность.

Так же происходит смена поколений программистов и желающих влезать в эту C-культуру 70-х и 80-х всё меньше и меньше.

Ну так пусть они напишут более безопасную замену libcrypt, если им так не нравится ЯП. Никто их в неволе не держит, и это не вселенная, а всего лишь либа. Вон, некоторые утилитки на расте переписывают. И, кстати, хоть язык родом из 70х, последний стандарт в 21 веке приняли, так что современный код точно не из 70x.

Примерно то же самое произошло с языком COBOL и с большим количеством кода, который на нём написан. Этим кодом сейчас занимаются практически одни лишь пенсионеры и от него всячески стараются избавиться.

Знаешь, вот железо ширпотреб тоже устаревает, и периодически через каждые N лет (и гораздо быстрее Кобола) железо «морально устаревает». И что теперь, ждать светлого будущего, и бояться, что сегодня купленное устареет через 5 лет, или использовать то, что есть, здесь и сейчас?

В случае C++ это всё тот же компилятор.

Все равно доп. зависимости. Вот у меня, например, в системе может не быть никакого рантайма C++. И что, теперь ограничивать libcrypt жирными системами или автору libcrypt надо будет вкрячивать рантайм плюсов статически в саму либу?

seiken ★★★★★ ()
Ответ на: комментарий от pihter

А чем плохи технологии 70-х?

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

thunar ★★★★★ ()
Последнее исправление: thunar (всего исправлений: 1)
Ответ на: комментарий от seiken

Все равно доп. зависимости. Вот у меня, например, в системе может не быть никакого рантайма C++. И что, теперь ограничивать libcrypt жирными системами или автору libcrypt надо будет вкрячивать рантайм плюсов статически в саму либу?

99% таких уязвимостей — это байтодрочерство при работе со строками и/или выход за границы буфера. Нормальыне строки, массивы и контроль типов — за собой тянут минимум.

thunar ★★★★★ ()
Последнее исправление: thunar (всего исправлений: 2)
Ответ на: комментарий от hummer

А как же миллионы глаз? Где они были все эти два года?

Миллиарды глаз смотрят на небо, и до сих никого нет на Марсе.

anonymous ()
Ответ на: комментарий от hummer

А ты где был? Ты же один их этих миллионов… Сейчас нет этих глаз, сейчас только потребители. Это раньше 1 из 10 читал исходники, а сейчас это 1 из 10000 или даже 1 из 1000000.

anonymous ()
Ответ на: комментарий от hummer

По твоему выделить в отдельное место проверку на границы это современно? Муахахааха етить ты невежда. Тут её вообще нет. А ошибка проверки может быть и в методе класса, только в это случае эта ошибка в конкретном месте, а в случаев классов хрен найдёшь.

Маня, с 70тых ничего не изменилось, вся современность заключается в том (за исключением новых алгоритмов ) что кишки скрывают от программиста давая интерфейс так же как от юзеров программисты скрывают код давая дада интерфейс. Если «говно» платочком прикрыть, но всё равно говно.

anonymous ()
Ответ на: комментарий от hummer

salozar> ассерты

hummer> ООП и инкапсуляция

Что из этого гарантирует хоть какую-то защиту от появления уязвимостей?

anonymous ()
Ответ на: комментарий от hummer

Миллионы подростков смотрят не в код, а на баб в мониторах.

dmial ()
Ответ на: комментарий от hummer

Ты так говоришь, как будто до 19 января этот код был почти два года заперт на ключ и никто не мог его изучать. Где был Эрик Реймонд с его базарной моделью разработки?

Ну, если не высасывать из пальца, то то, что уязвимость нашли за 10 дней после релиза таки вин

goingUp ★★★★★ ()
Последнее исправление: goingUp (всего исправлений: 1)
Ответ на: комментарий от hummer

Раз не понимаешь, значит не лезь. Или читай умные книжки и развивайся. На самом деле С++ делает код сложнее для восприятия, а не проще.

Harald ★★★★★ ()
Ответ на: комментарий от anonymous

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

anonymous ()
Ответ на: комментарий от hummer

Никто не знает точно когда нашли, известно когда публично опубликовали… и кстати нет никакой гарантии что это не специальная «закладка» хитро внедрённая

WindowsXP ★★ ()
Ответ на: комментарий от WindowsXP

Никто не знает точно когда нашли, известно когда публично опубликовали… и кстати нет никакой гарантии что это не специальная «закладка» хитро внедрённая

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

Oleg_Iu ()
Ответ на: комментарий от thunar

Это я к тому писал, что рекламируемый товарищем объектный подход не решает этой проблемы. Ну и наверное это не про сабж

pihter ★★★★ ()
Ответ на: комментарий от hummer

Ну давай, докажи мне, что инкапсуляция - это плохо.

он тебе не про это сказал, а про то, что код на си++ только сложнее читается, то есть упрятать код копирования буфера специфичный для этого дескриптора (или что там) можно и в си и сделать это проще-понятней.

pihter ★★★★ ()
Ответ на: комментарий от anonymous

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

всем на оберон

pihter ★★★★ ()
Ответ на: комментарий от anonymous

А ты где был? Ты же один их этих миллионов… Сейчас нет этих глаз, сейчас только потребители. Это раньше 1 из 10 читал исходники, а сейчас это 1 из 10000 или даже 1 из 1000000.

Так всё просто. Они читали исходники, потому что они же их и писали. А сейчас просто количество писателей даже стало меньше чем раньше, а количество потребителей продукта увеличилось в разы. И кто теперь будет смотреть все исходники? Потребители что-ли? С нулевой квалификацией в чём бы то ни было. Не смешно даже.

justAmoment ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.