В libjpeg-turbo, библиотеке для кодирования и декодирования изображений в формате JPEG, выявлена уязвимость (CVE-2019-2201), приводящая к целочисленному переполнению и последующему повреждению содержимого кучи при обработке определённым образом оформленных файлов в формате JPEG. Потенциально уязвимость не исключает возможность создания эксплоита для организации выполнения кода в системе (для атаки требуется обработка очень большого изображения с разрешением на уровне 26755 x 26755)...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=51847
Это для тех кто не понимает в соседней
> приводящая к целочисленному переполнениюСтранно. Обычно в программах, написанных на Си, такого не бывает. И тут нá тебе.
Ну всё таки С не ASM, очень секьюрно не напишеш, возможностей маловато.
Наоборот чем меньше возможностей тем безопаснее. Вот взять язык без указателей и вот как в них что-то сломать вообще не понятно
Вот взять водяной пистолет, и вот как из него можно застрелиться вообще непонятно. Они намного безопаснее обычных.
Всё дело в размере...
Странно, что ты не скинул ссылку на свою более быструю и качественную либу на твоём волшебном языке без переполнений.
Ничего странного в этом нет: все знают, что Си - это не только быстро, но и безопасно. Память под надежной охраной.
Так с кривыми руками и отсутвующей головой: никакие проверки диапазона - всёравно не помогают же, не Сишникам.
Хорошо быть тобой, мр. робот!
Откровенная подпись...
(p.s. всегда как программист знал что каптчи - фуфло против тролле-ботов,
и даже вероятно, когда каптча внешние например на др.сайтах, чисто предлог для [гугл] js-отслеживания)
Только вот "складывать" в памяти даже CISC не умеет, переполнение происходит в регистрах и это может произойти в любом "нативном" языке для базовых типов (если у вас какой-нибудь integer это объект, то сравнивать некоректно).
Этот любитель раста порвался, несите следующего!
Правило "Пусть каждая программа делает что-то одно, но хорошо" появилось именно из-за Си. Простую программу легко написать и легко проконтролировать работу с памятью, а вот большая софтина это уже многократно возросшая сложность и минное поле.
Да не из-за си, дурилка ты картонная, а из-за того, что сложность с ростом объёма вообще растёт нелинейно. Не зависит это языка. Ну и из-за того, что тогда софт нужен был тем, кто понимал, как им пользоваться, и комбинаторный взрыв возможностей - штука для компетентного пользователя крайне полезная.
По вашему те 70% ошибок работы с памятью, которые допустили программисты майкрософт пишущие на Си, будут магическим образом замещены ошибками другого типа?
> По вашему те 70% ошибок работы с памятью, которые допустили программисты майкрософт пишущие на Си, будут магическим образом замещены ошибками другого типа?Ну вообще-то да.
- SQL-инъекции,
- отсутствие проверок входных параметров,
- отсутствие проверки подписи ssl-сертификата,
- отсутствие проверок на граничные условия,
- утечка памяти из-за того, что вместо перезаписи старого элемента массива по ошибке всегда добавляем новый,
- проблемы связанные с неполным пониманием того, как КОНКРЕТНО работают 20 используемых сторонних библиотек,
- незначительное изменение поведения при обновлении версии сторонней библиотеки, которое в нашем случае привело к ошибке,
- похапе, яваскрипт, ява, никакого си.
А как <insert language name here> справляется с целочисленным переполнением при умножении двух случайных входящих чисел? Чтобы не подбирать Exception, или пробивать CPU Flag, на каждую математическую операцию. Простейший способ, в их варианте, было бы взять предположение что размер изображения не будет превышать 65535 по любой из сторон. Тогда результат умножения явно помещается в UInt32 откуда уже можно делать выводы о том как действовать дальше.
Простейший способ, в их варианте, было бы взять предположение что размер изображения не будет
превышать 65535 по любой из сторон.Вот так и появилось крылатое "640kb памчти хватит всем" :)
Вот сразу верю. Так и было!Stupid попытался сделать simple. Из рекомендации про simple нужно убрать обращение к stupid.
Иди учи мАтематику анон. 32битный такого размера это 16гиг
Некоторые <insert language name here> не допустят переполнения кучи.
>переполненияпереписания, извините
> А как <insert language name here> справляется с целочисленным переполнением при умножении
> двух случайных входящих чисел? Чтобы не подбирать Exception, или пробивать CPU Flag, на каждую математическую операцию.Нормально справляются:
https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins...
И пробивать обычно ничего не нужно: jo/jno/jс/bv<непомнючтотам> и т.д уже придумали давно.> The compiler will attempt to use hardware instructions to implement these built-in functions where possible, like conditional jump on overflow after addition, conditional jump on carry etc.
>
Засчитано. В кассу за гонораром.
За "вспомнити libjpeg-turbo" теперь тоже будут платить?
Турбо-уязвимость.
Uses crt;
> Uses crt;Тест на возраст? :D
На память
>повреждению содержимого кучиЧто за куча?
https://ru.wikipedia.org/wiki/Куча_(память)
спасибо, брат
Образование не нужно.
Так и вижу этот фикс:
+ if (x >= 26755 && y >= 26755)
+ return (EINVAL);А теперь оказалось что вариант когда x = 26754 а y = 999999 тоже надо фиксить :)
return это не функция и потому не требует скобок."Убивать надо таких знатоков" (c)
> return это не функция
>
>
> и потому не требует скобокНет, не потому. if тоже не функция, но скобки "почему-то" требует.
Я тоже держу под рукой справочник по c специально для опеннета
>return это не функция и потому не требует скобок.Ага, как и sizeof.
Требует.
Попробуй узнать размер int или char.
Зачем например? Принимаю, что у всех разный опыт, но даже вспомнить не могу, когда мне это требовалось. Для маллока всегда указываю в sizeof саму переменную.
> Зачем например?Чтобы увидеть ошибку и обратиться, наконец, к документации, вместо того, чтоб считать себя избранным, которому открылась истина.
Я в курсе, но предпочитаю использовать скобки по максимуму.
Даже в выражениях: int v = ((42 * 1024) + 32);
потому что я уже наступал всякие неявные грабли с этим.
Ты наверно делил x/y+z вместо x/(y+z) гуманитариям такое простительно.
> гуманитариям такое простительно.Зато технарям непростительно не ценить время того кто будет читать твой код
Согласен. Самый читабельный код - на лиспе.
Я готов понять, что вы не помните, что выполняется первым: умножение-деление или сложение-вычитание. Но вторые-то скобки зачем? Боитесь, что сначала оно присвоит результат умножения переменной, а потом добавит 32 в никуда?
Скорее привычка, я бы точно так же написал буть оно в if () или в аргументе макроса/функции, да и единообразность проще поддерживать.
К тому же при визуальном парсинге всё что внутри () легче вычленять как некий один объект.
И я не исключаю что всё ещё можно нарватся на странный компилятор или интерпретатор.
> К тому же при визуальном парсинге всё что внутри () легче вычленять как некий один объект.va(
vi(
?
+ if (x >= 26755 || y >= 26755)
+ return (EINVAL);
Я его починил!
+ if (x + y >= 53510)
+ return (EINVAL);
починил еще сильнее!
А если сумма будет отрицательной?
Будет новая фича.
если сумма будет отрицательной то свой жипег посмотрите в соседнем измерении
Тогда заменим int на uint32_t или size_t, ибо нефик!
А ведь можно пройти по ссылке и посмотреть. Но зачем, если можно просто пёрнуть в комментах.
Юзается в slim session manager.
Тот вроде уже давно всё, очень давно. Да и до того, как он был всё, его приходилось патчить ведром патчей. Это будет не единственная уязвимость в нём.У меня получился такой список уязвимого:
virtual/jpeg-0-r3
www-client/firefox-70.0.1
app-emulation/wine-staging-4.19
app-emulation/wine-vanilla-4.0.2
app-text/poppler-0.82.0
dev-python/pillow-6.2.1
dev-qt/qtgui-5.12.5
kde-apps/gwenview-19.08.3
kde-apps/okular-19.08.3
kde-frameworks/khtml-5.64.0
media-libs/gst-plugins-base-1.14.5-r1
media-libs/lcms-2.9
media-libs/libwebp-1.0.3
media-libs/tiff-4.1.0
media-video/mpv-0.30.0
x11-libs/gdk-pixbuf-2.40.0Т.е. примерно 100% софта. Неприятненько.
Кстааати, о пользе бандленного софта: это же факт, что куча проектов используют уязвимую библиотеку и не зависят от системной. Включая firefox? Я нашёл только упоминания о версии 2.0.0 в исходниках. Но, впрочем я не нашёл и файлов, которые затрагивали исправления (их там нет?), хотя это ни о чём не говорит. Налицо спланированная акция против госслужб с файрфоксом? Надо было пользоваться IE. [trollface]
Список по оформлению уж очень напоминает гентушный :).
> Т.е. примерно 100% софта. Неприятненько.ну а чего ты хочешь - эпоха зависимостей всего от всего. И "опенсорсного" софта, собираемого единственноверным образом с максимумом включенных крыжиков (вот например - libtiff'у эта зависимость прям охрененно нужна. Наверное, есть целый один экземпляр tiff-файла с jpeg-encoded внутри. В парижской палате мер и весов хранится, где-то в соседнем шкафу с эталонным ненужно.)
отдельный, понятно, вопрос, для чего на самом деле типовой линуксер использует что-то что на самом деле использует libtiff.
Мне повезло, в моём дистрибутиве можно собирать с минимумом зависимостей. И libtiff собран без jpeg и и jbig (что это вообще?), зато с webp. А libwebp уже собран с jpeg (и png), не знаю зачем они ему. Скорее всего иначе будет не сконвертировать эти файлы в webp штатной конвертилкой.А вот вне опенсорса сложнее, та же libjpeg-turbo из новости в "проприетарном" софте будет идти статически скомпилированной и пользователь даже не узнает об уязвимостях.
> Мне повезло, в моём дистрибутиве можно собирать с минимумом зависимостей.тут надо скорее дистрибутив, где можно собрать несколько версий и выбрать нужную для конкретного применения. Но таких не видно (а если и сделать - будет чудовищно криво).
> JBIG is an early lossless image compression standard from the Joint Bi-level Image Experts Group
встречается даже еще чаще чем jpeg внутри tiff - то есть примерно никогда. Где-то рядом с jpeg2000.
> А вот вне опенсорса сложнее, та же libjpeg-turbo из новости в "проприетарном" софте будет идти
> статически скомпилированной и пользователь даже не узнает об уязвимостях.ну вот она у тебя в мурзиле статически скомпилированная, об уязвимости ты знаешь - и что толку?
>в мурзиле статически скомпилированнаяМурзила собрана llvm и с пульсой, поэтому я пересобираю её с gcc и без пульсы. Каких-либо особых затрат это не стоит: раньше обновление было 15 минут вместо 1, теперь с рустом дополнительно несколько часов уходит на руст.
>что толку
Как только она обновится, весь софт от неё зависящий тут же исправится (но всё же передаём привет мурзиле, которая бандлит библиотеки), и голова не будет болеть о том что где-то остались дыры.
Мурзиле разве в генте нельзя сказать, чтобы системные использовала? палемуну можно
Можно, собственно так и делаю. Но тогда системные библиотеки привязаны к мурзиле, а это возможно ещё хуже чем уязвимая мурзила.
>ну вот она у тебя в мурзиле статически скомпилированная, об уязвимости ты знаешь - и что толку?Мурзиллу эта уязвимость затрагивает чуть менее, чем никак
>jbig (что это вообще?)Алгоритм сжатия монохромных изображений, используется, например, в PDF
Я уже понял, это можно использовать для двухцветных сканов типа факсов. Tiff тоже для сканов применяется.
Не обязательно двухцветных, можно внутри PDF сделать слоенку типа DjVu, с основным двухцветным слоем и цветными background и foreground
Да и внутри TIFF тоже можно, т.к. там есть слои
Неудачный пример. Конкретно libtiff надо собирать примерно со всем - если, конечно, вас вообще tiff интересует, а не "чтобы сорабось что-то ещё, от ней зависящее". Пихают в него аж бегом и jpeg и чёрта лысого.
>отдельный, понятно, вопрос, для чего на самом деле типовой линуксер использует что-то что на самом деле использует libtiff.Чтобы открывать TIFF-файлы, для чего же еще. А в TIFF-файле может быть много чего, в том числе и JPEG
Во фрёвых портах он вполне себе живой.
Но я посмотрел в код, это конечно очень ужасно, понятно почему оно умерло - не знаешь с чего начать переписывать :)Сморел LightDM, но не сильно внутрь, в целом не плохо, но на мой вкус ровно те же болячки что и у слима - оно не умеет:
- запускать хорг с повышенным приоритетом
- делать чтобы хоргу не приходил оом киллер
- делать нормальный логон в систему подобно su -l, так чтобы login.conf и прочее отрабатывалосьЗато умеет:
- вроде как переключение юзеров
- чуть более вменяемый гуй с плагинами
- какие то доп переменные среды выставляет
И что из этого списка использует API TurboJPEG? Вангую, что ничего
>Тот вроде уже давно всё, очень давно. Да и до того, как он был всё, его приходилось патчить ведром патчей.Странно, у меня в генте просто работает
Я раньше пользовался, баги лезли регулярно.>в генте
Ну как тебе сказать... Оно то может и работает, но... Это сродни использованию исключительно софта на gtk1 (по религиозным причинам).
Тулкитофобия это болезнь. Если бы я например не перешел на mocp, без проблем пользовался бы сейчас xmms на gtk1
> Тулкитофобия это болезнь. Если бы я например не перешел на mocp, без
> проблем пользовался бы сейчас xmms на gtk1Проблема скорее в дырах и в том, что старый гтк не оч сегодня, совсем не оч, а не в фобиях. Новый гтк не оч по другим причинам. Я вот даже к wxgtk нормально отношусь, если он работает и его достаточно, но он довольно куцый. Те же куцые файловые диалоги из гтк мешают.
> Т.е. примерно 100% софта. Неприятненько.Ну бывает ещё, что использующий библиотеку софт, например, не использует прям все-все-все возможности бибилиотеки или использует со своими собственными ограничениями на входные данные (например, сам отбрасывает изображения больше чем 20000 x 20000 и т. п.) или ещё каким-то образом (случайно или намеренно) никогда не создают в работе условия для проявления уязвимости.
Я не утверждаю и не оправдываю, нет. Просто, мне кажется, выводы про уязвимость уж сразу всего зависимого софта слегка поспешные.
А не помог ли бы тут fuzzing? Эта библиотека — критический системный софт, могли бы и потестировать.
>А не помог ли бы тут fuzzing?Фуззили бы все равно API libjpeg, в котором нет уязвимостей, а не API TurboJPEG, которым никто не пользуется
Почему тогда новость не звучит как "уязвимость в TurboJPEG апи библиотеки libjpeg-turbo"? Не ясно вообще зачем оно нужно, тут вроде говорят что оно не нужно https://libjpeg-turbo.org/About/TurboJPEG// Фуззили бы кусками? Наверняка в какой-нибудь джаве и турбо апи используется.
>Почему тогда новость не звучит как "уязвимость в TurboJPEG апи библиотеки libjpeg-turbo"?Потому что авторы новостей не опускаются до изучения технических подрбностей, надо делать побольше новостей и пожелтее заголовки
>для атаки требуется обработка очень большого изображения с разрешением на уровне 26755 x 26755Веб-макаки в опасносте!
Причем здесь веб-макаки? Уязвимость затрагивает только API TurboJPEG, а браузеры (и 99% всего остального софта) используют API libjpeg
Переживаешь за сородичей?
Либру офис можно ронять через этот баг. Но зачем?
> Либру офис можно ронять через этот баг. Но зачем?Затем же, зачем овнят корпоративные системы и госсектор через макросы вба, разницы примерно нет. Открываешь документ с почты и привет.
if (retval > (unsigned long long)((unsigned long)-1))
THROWG("tjBufSize(): Image is too large");
Выглядит так себе, прямо скажем. Пора переписать на расте красиво
> В дистрибутивах проблема остаётся неисправленнойВ арче, как обычно, все исправлено: https://www.archlinux.org/packages/extra/x86_64/libjpeg-turbo/