The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Уязвимость в библиотеке libjpeg-turbo

12.11.2019 22:17

В libjpeg-turbo, библиотеке для кодирования и декодирования изображений в формате JPEG, выявлена уязвимость (CVE-2019-2201), приводящая к целочисленному переполнению и последующему повреждению содержимого кучи при обработке определённым образом оформленных файлов в формате JPEG. Потенциально уязвимость не исключает возможность создания эксплоита для организации выполнения кода в системе (для атаки требуется обработка очень большого изображения с разрешением на уровне 26755 x 26755).

Проблема без лишней огласки исправлена в выпуске 2.0.3, но, судя по всему, устранена не полностью и остаются дополнительные векторы атаки. В дистрибутивах проблема остаётся неисправленной (Debian, SUSE/openSUSE, RHEL, Fedora, Ubuntu).

  1. Главная ссылка к новости (https://www.openwall.com/lists...)
  2. OpenNews: Доступна библиотека libjpeg-turbo 2.0
  3. OpenNews: Google представил OSS-Fuzz, сервис для анализа безопасности открытого ПО
  4. OpenNews: Доступна библиотека libjpeg-turbo 1.5.0
  5. OpenNews: Релиз библиотеки Libjpeg 9 с поддержкой режима сжатия без потерь
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/51847-libjpeg-turbo
Ключевые слова: libjpeg-turbo
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (91) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 22:19, 12/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Это для тех кто не понимает в соседней
     
  • 1.2, Аноним (2), 22:28, 12/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    > приводящая к целочисленному переполнению

    Странно. Обычно в программах, написанных на Си, такого не бывает. И тут нá тебе.

     
     
  • 2.8, VINRARUS (ok), 23:28, 12/11/2019 [^] [^^] [^^^] [ответить]  
  • –10 +/
    Ну всё таки С не ASM, очень секьюрно не напишеш, возможностей маловато.
     
     
  • 3.44, Аноним (44), 15:31, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Наоборот чем меньше возможностей тем безопаснее. Вот взять язык без указателей и вот как в них что-то сломать вообще не понятно
     
     
  • 4.76, draw1 (?), 23:03, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вот взять водяной пистолет, и вот как из него можно застрелиться вообще непонятно. Они намного  безопаснее обычных.
     
     
  • 5.83, saw (??), 07:31, 14/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Всё дело в размере...
     
  • 2.11, Аноним (11), 23:59, 12/11/2019 [^] [^^] [^^^] [ответить]  
  • +16 +/
    Странно, что ты не скинул ссылку на свою более быструю и качественную либу на твоём волшебном языке без переполнений.
     
     
  • 3.13, Аноним (2), 00:05, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • –11 +/
    Ничего странного в этом нет: все знают, что Си - это не только быстро, но и безопасно. Память под надежной охраной.
     
     
  • 4.17, Аноним (17), 02:18, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +12 +/
    Так с кривыми руками и отсутвующей головой: никакие проверки диапазона - всёравно не помогают же, не Сишникам.
     
     
  • 5.65, Аноним (-), 17:52, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Хорошо быть тобой, мр. робот!
     
     
  • 6.92, Аноним (92), 00:04, 17/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Откровенная подпись...
    (p.s. всегда как программист знал что каптчи - фуфло против тролле-ботов,
    и даже вероятно, когда каптча внешние например на др.сайтах, чисто предлог для [гугл] js-отслеживания)
     
  • 4.30, asdasd (?), 09:12, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Только вот "складывать" в памяти даже CISC не умеет, переполнение происходит в регистрах и это может произойти в любом "нативном" языке для базовых типов (если у вас какой-нибудь integer это объект, то сравнивать некоректно).
     
  • 4.72, Аноним (72), 19:51, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Этот любитель раста порвался, несите следующего!
     
  • 2.19, EnemyOfDemocracy (?), 03:20, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Правило "Пусть каждая программа делает что-то одно, но хорошо" появилось именно из-за Си. Простую программу легко написать и легко проконтролировать работу с памятью, а вот большая софтина это уже многократно возросшая сложность и минное поле.
     
     
  • 3.21, Crazy Alex (ok), 03:42, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Да не из-за си, дурилка ты картонная, а из-за того, что сложность с ростом объёма вообще растёт нелинейно. Не зависит это языка. Ну и из-за того, что тогда софт нужен был тем, кто понимал, как им пользоваться, и комбинаторный взрыв возможностей - штука для компетентного пользователя крайне полезная.
     
     
  • 4.66, Аноним (-), 18:09, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    По вашему те 70% ошибок работы с памятью, которые допустили программисты майкрософт пишущие на Си, будут магическим образом замещены ошибками другого типа?
     
     
  • 5.80, Аноним (80), 23:46, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > По вашему те 70% ошибок работы с памятью, которые допустили программисты майкрософт пишущие на Си, будут магическим образом замещены ошибками другого типа?

    Ну вообще-то да.

    - SQL-инъекции,
    - отсутствие проверок входных параметров,
    - отсутствие проверки подписи ssl-сертификата,
    - отсутствие проверок на граничные условия,
    - утечка памяти из-за того, что вместо перезаписи старого элемента массива по ошибке всегда добавляем новый,
    - проблемы связанные с неполным пониманием того, как КОНКРЕТНО работают 20 используемых сторонних библиотек,
    - незначительное изменение поведения при обновлении версии сторонней библиотеки, которое в нашем случае привело к ошибке,
    - похапе, яваскрипт, ява, никакого си.

     
  • 2.25, Иваныч (??), 06:34, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А как <insert language name here> справляется с целочисленным переполнением при умножении двух случайных входящих чисел? Чтобы не подбирать Exception, или пробивать CPU Flag, на каждую математическую операцию. Простейший способ, в их варианте, было бы взять предположение что размер изображения не будет превышать 65535 по любой из сторон. Тогда результат умножения явно помещается в UInt32 откуда уже можно делать выводы о том как действовать дальше.
     
     
  • 3.27, Аноним (27), 08:20, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Простейший способ, в их варианте, было бы взять предположение что размер изображения не будет
    превышать 65535 по любой из сторон.

    Вот так и появилось крылатое "640kb памчти хватит всем" :)

     
     
  • 4.31, А (??), 10:35, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вот сразу верю. Так и было!

    Stupid попытался сделать simple. Из рекомендации про simple нужно убрать обращение к stupid.

     
  • 4.82, Аноним (82), 07:28, 14/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Иди учи мАтематику анон. 32битный такого размера это 16гиг
     
  • 3.67, Аноним (-), 18:10, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Некоторые <insert language name here> не допустят переполнения кучи.
     
     
  • 4.68, Аноним (-), 18:11, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >переполнения

    переписания, извините

     
  • 3.89, Аноним84701 (ok), 16:44, 14/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > А как <insert language name here> справляется с целочисленным переполнением при умножении
    > двух случайных входящих чисел? Чтобы не подбирать Exception, или пробивать CPU Flag, на каждую математическую операцию.

    Нормально справляются:
    https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html
    И пробивать обычно ничего не нужно: 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.
    >

     
  • 2.26, Аноним (26), 07:23, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Засчитано. В кассу за гонораром.
     
     
  • 3.28, Аноним (28), 08:32, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    За "вспомнити libjpeg-turbo" теперь тоже будут платить?
     

  • 1.3, Аноним (3), 22:32, 12/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Турбо-уязвимость.
     
     
  • 2.14, A.Stahl (ok), 00:09, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Uses crt;
     
     
  • 3.18, Аноним (18), 03:19, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +8 +/
    > Uses crt;

    Тест на возраст? :D

     
     
  • 4.35, Аноним (35), 12:05, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    На память
     

  • 1.4, Аноним (4), 22:36, 12/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –11 +/
    >повреждению содержимого кучи

    Что за куча?

     
     
  • 2.5, Sluggard (ok), 22:47, 12/11/2019 [^] [^^] [^^^] [ответить]  
  • +6 +/
    https://ru.wikipedia.org/wiki/Куча_(память)
     
     
  • 3.6, Аноним (4), 22:49, 12/11/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    спасибо, брат
     
     
  • 4.56, Аноним (56), 16:57, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Образование не нужно.
     

  • 1.7, Ivan_83 (ok), 23:27, 12/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Так и вижу этот фикс:
    + if (x >= 26755 && y >= 26755)
    +  return (EINVAL);

    А теперь оказалось что вариант когда x = 26754 а y = 999999 тоже надо фиксить :)

     
     
  • 2.9, Аноним (9), 23:47, 12/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    return это не функция и потому не требует скобок.

    "Убивать надо таких знатоков" (c)

     
     
  • 3.10, Аноним (2), 23:53, 12/11/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > return это не функция
    >
    >
    > и потому не требует скобок

    Нет, не потому. if тоже не функция, но скобки "почему-то" требует.

     
  • 3.12, Аноним (11), 00:00, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Я тоже держу под рукой справочник по c специально для опеннета
     
  • 3.20, anon2 (?), 03:42, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >return это не функция и потому не требует скобок.

    Ага, как и sizeof.

     
     
  • 4.78, Аноним (78), 23:16, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Требует.
    Попробуй узнать размер int или char.
     
     
  • 5.85, Аноним (85), 12:17, 14/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем например? Принимаю, что у всех разный опыт, но даже вспомнить не могу, когда мне это требовалось. Для маллока всегда указываю в sizeof саму переменную.
     
     
  • 6.90, Аноним (78), 00:07, 16/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Зачем например?

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

     
  • 3.46, Ivan_83 (ok), 15:35, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Я в курсе, но предпочитаю использовать скобки по максимуму.
    Даже в выражениях: int v = ((42 * 1024) + 32);
    потому что я уже наступал всякие неявные грабли с этим.
     
     
  • 4.70, Аноним (70), 19:15, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ты наверно делил x/y+z вместо x/(y+z) гуманитариям такое простительно.
     
     
  • 5.77, draw1 (?), 23:08, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > гуманитариям такое простительно.

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

     
     
  • 6.86, Аноним (85), 12:19, 14/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Согласен. Самый читабельный код - на лиспе.
     
  • 4.87, Аноним (85), 12:25, 14/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Я готов понять, что вы не помните, что выполняется первым: умножение-деление или сложение-вычитание. Но вторые-то скобки зачем? Боитесь, что сначала оно присвоит результат умножения переменной, а потом добавит 32 в никуда?
     
     
  • 5.88, Ivan_83 (ok), 13:03, 14/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Скорее привычка, я бы точно так же написал буть оно в if () или в аргументе макроса/функции, да и единообразность проще поддерживать.
    К тому же при визуальном парсинге всё что внутри () легче вычленять как некий один объект.
    И я не исключаю что всё ещё можно нарватся на странный компилятор или интерпретатор.
     
     
  • 6.91, Аноним (78), 00:10, 16/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > К тому же при визуальном парсинге всё что внутри () легче вычленять как некий один объект.

    va(
    vi(
    ?

     
  • 2.15, Аноним (15), 00:22, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    + if (x >= 26755 || y >= 26755)
    +  return (EINVAL);
    Я его починил!
     
     
  • 3.33, Аноним (33), 11:46, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    + if (x + y >= 53510)
    +  return (EINVAL);
    починил еще сильнее!
     
     
  • 4.38, КО (?), 13:30, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А если сумма будет отрицательной?
     
     
  • 5.40, Аноним (40), 14:02, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Будет новая фича.
     
  • 5.42, bvs23bkv33 (?), 15:19, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    если сумма будет отрицательной то свой жипег посмотрите в соседнем измерении
     
  • 5.47, Ivan_83 (ok), 15:37, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Тогда заменим int на uint32_t или size_t, ибо нефик!
     
  • 2.49, Аноним (49), 15:59, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А ведь можно пройти по ссылке и посмотреть. Но зачем, если можно просто пёрнуть в комментах.
     

  • 1.16, Аноним (16), 01:44, 13/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Юзается в slim session manager.
     
     
  • 2.22, Аноним (22), 05:17, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Тот вроде уже давно всё, очень давно. Да и до того, как он был всё, его приходилось патчить ведром патчей. Это будет не единственная уязвимость в нём.

    У меня получился такой список уязвимого:

    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% софта. Неприятненько.

     
     
  • 3.24, Аноним (22), 06:05, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Кстааати, о пользе бандленного софта: это же факт, что куча проектов используют уязвимую библиотеку и не зависят от системной. Включая firefox? Я нашёл только упоминания о версии 2.0.0 в исходниках. Но, впрочем я не нашёл и файлов, которые затрагивали исправления (их там нет?), хотя это ни о чём не говорит. Налицо спланированная акция против госслужб с файрфоксом? Надо было пользоваться IE. [trollface]
     
  • 3.29, ryoken (ok), 08:56, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Список по оформлению уж очень напоминает гентушный :).
     
  • 3.32, MS (??), 11:18, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Т.е. примерно 100% софта. Неприятненько.

    ну а чего ты хочешь - эпоха зависимостей всего от всего. И "опенсорсного" софта, собираемого единственноверным образом с максимумом включенных крыжиков (вот например - libtiff'у эта зависимость прям охрененно нужна. Наверное, есть целый один экземпляр tiff-файла с jpeg-encoded внутри. В парижской палате мер и  весов хранится, где-то в соседнем шкафу с эталонным ненужно.)

    отдельный, понятно, вопрос, для чего на самом деле типовой линуксер использует что-то что на самом деле использует libtiff.

     
     
  • 4.34, Аноним (22), 12:00, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Мне повезло, в моём дистрибутиве можно собирать с минимумом зависимостей. И libtiff собран без jpeg и и jbig (что это вообще?), зато с webp. А libwebp уже собран с jpeg (и png), не знаю зачем они ему. Скорее всего иначе будет не сконвертировать эти файлы в webp штатной конвертилкой.

    А вот вне опенсорса сложнее, та же libjpeg-turbo из новости в "проприетарном" софте будет идти статически скомпилированной и пользователь даже не узнает об уязвимостях.

     
     
  • 5.36, пох. (?), 12:18, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Мне повезло, в моём дистрибутиве можно собирать с минимумом зависимостей.

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

    > JBIG is an early lossless image compression standard from the Joint Bi-level Image Experts Group

    встречается даже еще чаще чем jpeg внутри tiff - то есть примерно никогда. Где-то рядом с jpeg2000.

    > А вот вне опенсорса сложнее, та же libjpeg-turbo из новости в "проприетарном" софте будет идти
    > статически скомпилированной и пользователь даже не узнает об уязвимостях.

    ну вот она у тебя в мурзиле статически скомпилированная, об уязвимости ты знаешь - и что толку?

     
     
  • 6.37, Аноним (22), 12:27, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >в мурзиле статически скомпилированная

    Мурзила собрана llvm и с пульсой, поэтому я пересобираю её с gcc и без пульсы. Каких-либо особых затрат это не стоит: раньше обновление было 15 минут вместо 1, теперь с рустом дополнительно несколько часов уходит на руст.

    >что толку

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

     
     
  • 7.50, Crazy Alex (ok), 16:02, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Мурзиле разве в генте нельзя сказать, чтобы системные использовала? палемуну можно
     
     
  • 8.52, Аноним (22), 16:45, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Можно, собственно так и делаю Но тогда системные библиотеки привязаны к мурзиле... текст свёрнут, показать
     
  • 6.61, Аноним (61), 17:25, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >ну вот она у тебя в мурзиле статически скомпилированная, об уязвимости ты знаешь - и что толку?

    Мурзиллу эта уязвимость затрагивает чуть менее, чем никак

     
  • 5.43, Аноним (61), 15:27, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >jbig (что это вообще?)

    Алгоритм сжатия монохромных изображений, используется, например, в PDF

     
     
  • 6.45, Аноним (22), 15:33, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Я уже понял, это можно использовать для двухцветных сканов типа факсов. Tiff тоже для сканов применяется.
     
     
  • 7.59, Аноним (61), 17:22, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Не обязательно двухцветных, можно внутри PDF сделать слоенку типа DjVu, с основным двухцветным слоем и цветными background и foreground
     
     
  • 8.60, Аноним (61), 17:24, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Да и внутри TIFF тоже можно, т к там есть слои... текст свёрнут, показать
     
  • 4.51, Crazy Alex (ok), 16:04, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Неудачный пример. Конкретно libtiff надо собирать примерно со всем - если, конечно, вас вообще tiff интересует, а не "чтобы сорабось что-то ещё, от ней зависящее". Пихают в него аж бегом и jpeg и чёрта лысого.
     
  • 4.53, Аноним (61), 16:46, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >отдельный, понятно, вопрос, для чего на самом деле типовой линуксер использует что-то что на самом деле использует libtiff.

    Чтобы открывать TIFF-файлы, для чего же еще. А в TIFF-файле может быть много чего, в том числе и JPEG

     
  • 3.48, Ivan_83 (ok), 15:46, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Во фрёвых портах он вполне себе живой.
    Но я посмотрел в код, это конечно очень ужасно, понятно почему оно умерло - не знаешь с чего начать переписывать :)

    Сморел LightDM, но не сильно внутрь, в целом не плохо, но на мой вкус ровно те же болячки что и у слима - оно не умеет:
    - запускать хорг с повышенным приоритетом
    - делать чтобы хоргу не приходил оом киллер
    - делать нормальный логон в систему подобно su -l, так чтобы login.conf и прочее отрабатывалось

    Зато умеет:
    - вроде как переключение юзеров
    - чуть более вменяемый гуй с плагинами
    - какие то доп переменные среды выставляет

     
  • 3.58, Аноним (61), 17:20, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    И что из этого списка использует API TurboJPEG? Вангую, что ничего
     
  • 3.62, Аноним (61), 17:29, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >Тот вроде уже давно всё, очень давно. Да и до того, как он был всё, его приходилось патчить ведром патчей.

    Странно, у меня в генте просто работает

     
     
  • 4.64, Аноним (22), 17:45, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Я раньше пользовался, баги лезли регулярно.

    >в генте

    Ну как тебе сказать... Оно то может и работает, но... Это сродни использованию исключительно софта на gtk1 (по религиозным причинам).

     
     
  • 5.74, Аноним (74), 21:28, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тулкитофобия это болезнь. Если бы я например не перешел на mocp, без проблем пользовался бы сейчас xmms на gtk1
     
     
  • 6.75, Аноним (22), 22:27, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Тулкитофобия это болезнь. Если бы я например не перешел на mocp, без
    > проблем пользовался бы сейчас xmms на gtk1

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

     
  • 3.79, draw1 (?), 23:20, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Т.е. примерно 100% софта. Неприятненько.

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

    Я не утверждаю и не оправдываю, нет. Просто, мне кажется, выводы про уязвимость уж сразу всего зависимого софта слегка поспешные.

     

  • 1.23, Аноним (22), 05:21, 13/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А не помог ли бы тут fuzzing? Эта библиотека — критический системный софт, могли бы и потестировать.
     
     
  • 2.57, Аноним (61), 17:19, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >А не помог ли бы тут fuzzing?

    Фуззили бы все равно API libjpeg, в котором нет уязвимостей, а не API TurboJPEG, которым никто не пользуется

     
     
  • 3.63, Аноним (22), 17:39, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Почему тогда новость не звучит как "уязвимость в TurboJPEG апи библиотеки libjpeg-turbo"? Не ясно вообще зачем оно нужно, тут вроде говорят что оно не нужно https://libjpeg-turbo.org/About/TurboJPEG

    // Фуззили бы кусками? Наверняка в какой-нибудь джаве и турбо апи используется.

     
     
  • 4.69, Аноним (61), 18:11, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >Почему тогда новость не звучит как "уязвимость в TurboJPEG апи библиотеки libjpeg-turbo"?

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

     

  • 1.41, Pistrun (?), 14:40, 13/11/2019 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • +/
     

     ....ответы скрыты (2)

  • 1.71, Аноним (70), 19:17, 13/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Либру офис можно ронять через этот баг. Но зачем?
     
     
  • 2.73, Аноним (22), 20:55, 13/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Либру офис можно ронять через этот баг. Но зачем?

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

     

  • 1.81, Анонрррррр (?), 00:13, 14/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    if (retval > (unsigned long long)((unsigned long)-1))
        THROWG("tjBufSize(): Image is too large");

    Выглядит так себе, прямо скажем. Пора переписать на расте красиво

     
  • 1.84, trolleybus (?), 09:21, 14/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > В дистрибутивах проблема остаётся неисправленной

    В арче, как обычно, все исправлено: https://www.archlinux.org/packages/extra/x86_64/libjpeg-turbo/

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру