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 [^] [^^] [^^^] [ответить]
| +/– |
Вот взять водяной пистолет, и вот как из него можно застрелиться вообще непонятно. Они намного безопаснее обычных.
| |
|
|
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 +/– |
Так с кривыми руками и отсутвующей головой: никакие проверки диапазона - всёравно не помогают же, не Сишникам.
| |
|
|
6.92, Аноним (92), 00:04, 17/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
Откровенная подпись...
(p.s. всегда как программист знал что каптчи - фуфло против тролле-ботов,
и даже вероятно, когда каптча внешние например на др.сайтах, чисто предлог для [гугл] js-отслеживания)
| |
|
|
4.30, asdasd (?), 09:12, 13/11/2019 [^] [^^] [^^^] [ответить]
| +3 +/– |
Только вот "складывать" в памяти даже CISC не умеет, переполнение происходит в регистрах и это может произойти в любом "нативном" языке для базовых типов (если у вас какой-нибудь integer это объект, то сравнивать некоректно).
| |
|
|
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.
| |
|
3.67, Аноним (-), 18:10, 13/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
Некоторые <insert language name here> не допустят переполнения кучи.
| |
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.
> | |
|
|
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.
| |
|
|
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 +/– |
> гуманитариям такое простительно.
Зато технарям непростительно не ценить время того кто будет читать твой код
| |
|
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);
починил еще сильнее!
| |
|
2.49, Аноним (49), 15:59, 13/11/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
А ведь можно пройти по ссылке и посмотреть. Но зачем, если можно просто пёрнуть в комментах.
| |
|
|
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.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
| |
|
|
|
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"?
Потому что авторы новостей не опускаются до изучения технических подрбностей, надо делать побольше новостей и пожелтее заголовки
| |
|
|
|
|
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");
Выглядит так себе, прямо скажем. Пора переписать на расте красиво
| |
|