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

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

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

Версия 1.9.0 вышла 19 января 2020 года. Уязвимость нашли 28 января. Недостаточно быстро?

нашли, продали кому надо, кто надо попользовался, через 2 года выложили в паблик и объявили 0-day

неким Tavis Ormandy

поржал

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

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

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

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

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

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

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

‘_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.

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

Из-за этого надо просто переходить на ООП и инкапсуляцию.

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

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

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

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

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», вполне по-опенсорски.

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

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

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

таком явлении как нечитабельный код

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 % pkg query '%v' libgcrypt
1.8.7

Я спокоен. :3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ну тут же не много вариантов. Либо кто-то пилит 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 надо будет вкрячивать рантайм плюсов статически в саму либу?

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

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

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

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

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

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

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

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

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

salozar> ассерты

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

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

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

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

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

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

У тебя аргументация на уровне детского сада.

у тебя не лучше

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

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

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

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

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

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

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

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

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

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

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

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

и что в ней нечитаемо?