1.9, Аноним (9), 16:45, 16/06/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +10 +/– |
Открыл первый попавшийся исходник https://gitlab.com/ImageMagick/ImageMagick/blob/master/MagickWand/compare.c: функция на 1200 строк, парсинг аргументов вперемешку с логикой, if внутри switch внутри switch, внутри else, внутри else. Никакой обфускатор так не сможет.
Я не удивлён, что в *Magick столько уязвимостей, но я удивлён, что это всё вообще работает. Видимо название придумано не зря - именно на магии это всё и держится.
| |
|
2.16, Аноним (16), 19:00, 16/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
То что ImageMagick - свалка ископаемого г.внокода ни для кого не секрет.
| |
2.22, Наноним (?), 06:04, 17/06/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Когда твой красивый аккуратный код по всем бест практисам никому не сдался, и остаётся брызгать слюной на "уродливый", но намного более полезный
| |
|
3.25, Попугай Кеша (?), 09:34, 17/06/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
Вы просто не понимаете еще, опыта мало у вас. Когда такой гений-выскочка пишет код - ему хорошо. Когда он уходит из проекта - другим нужно полгода-год, чтобы разобраться, что он понаписал.
Бест практисес не просто так же придумываются
| |
|
|
1.3, Аноним (3), 13:45, 16/06/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
> 14 уязвимостей, которые могут привести к переполнению буфера
Картина Репина "Си-программисты работают с буфером"
| |
|
2.6, OpenEcho (?), 15:18, 16/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
Понизить их в должности до Бэйсик программиста, там явных буферов нет...
| |
2.10, anonymous (??), 16:45, 16/06/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
Если ваша позиция с том, что Си не нужен, или в том, что GraphicsMagick нужно было писать, например, на Java, то, конечно, удачи вам, когда будете делать аналогичный проект :)
| |
|
3.12, Аноним (3), 17:17, 16/06/2019 [^] [^^] [^^^] [ответить]
| –3 +/– |
Помнишь времена, когда через ИК-порт передавали друг другу мобильные Java-игры (J2ME)? Заметь, что на тех хилых девайсах это были именно Java-, а не си-игры, и с рисованием графики там проблем не было. В особенности не было переполнений буферов.
| |
|
|
5.15, Аноним (15), 18:29, 16/06/2019 [^] [^^] [^^^] [ответить]
| +3 +/– |
А вот и Шигорин с первым попавшимся результатом Гугла по запросу "J2ME уязвимости смотреть список бесплатно без регистрации"
| |
5.18, Аноним (3), 20:21, 16/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
Черт возьми, а ведь и впрямь линчуют негров... И [eq поспоришь блин...
| |
|
4.24, anonymous (??), 09:23, 17/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
О да, это одно и то же, что и скоростная обработка множества больших изображений :)
| |
4.32, Аноним (32), 17:38, 18/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
>переполнений буферов
Ваша фраза в таком виде может быть воспринята иначе, чем вы задумывали... ...или вы так и задумывали?
| |
|
|
|
1.23, Аноним (23), 07:51, 17/06/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> в GraphicsMagick 1.3.32 также устранено 14 уязвимостей, которые могут привести к переполнению буфера при обработке специально оформленных изображений в форматах SVG, BMP, DIB, MIFF, MAT, MNG, TGA, TIFF, WMF и XWD.
Какие же вы упортые, пользователи x86. Вот в процах от IBM на аппаратном уровне есть запрет выделения памяти в режиме WX (одновременно для изменения и исполнения).
Если сборщики дистров будут строго следовать главному правилу построения безопасных ОС: "все что исполняется не должно изменятся,а что изменяется исполнятся", то переполнения буфера перестанет быть потенциальной уязвимостью.
Протестируйте свой дистр с помощью paxtest на предмет корректной работы с оперативной памятью.
| |
|
2.26, Аноним (26), 11:47, 17/06/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Протестируйте свой дистр с помощью paxtest на предмет корректной работы с оперативной памятью.
Ну убедимся, что весь JIT отвалится. Что дальше?
| |
|
|
4.29, Аноним (29), 19:17, 17/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
Правильно настроение ядро Linux+PAX действительно отрубить весь код с JIT.
Почти все программы сегодня поддерживают сборку без JIT. Так в Gentoo надо указать USE="-jit".
Лучше сразу при сборке пакетов оптимизировать под ваш проц! Зачем оптимизировать (изменять код) при исполнении?
Правильная разработка программы с JIT это ветвление на два кода с JIT и без с возможностью выбора ветки в опции configure --nojit при компиляции кода.
| |
|
|
2.28, Аноним84701 (ok), 12:11, 17/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Если сборщики дистров будут строго следовать главному правилу построения безопасных ОС:
> "все что исполняется не должно изменятся,а что изменяется исполнятся", то переполнения
> буфера перестанет быть потенциальной уязвимостью.
Для начала им придется выкинуть питон, sh, перл.
Потому что у всех интерпретируемых ЯП с (разновидностью) eval это "не баг, а фича", совсем без переполнения буфера.
| |
|
3.30, Аноним (29), 19:21, 17/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
Интерпретируемые языки легко ограничить с помощью chmod, chown. Создать двух пользователей, одному разрешить использовать интерпретаторы, другому нет.
Для работы в десктопе с бровзером интерпретаторы не нужны.
| |
|
4.31, Аноним (31), 11:29, 18/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
Скажи это половине инфраструктуры, обеспечивающей твой десктоп. Всякие firewalld, tuned, подозреваю, что и тот же gnome и энная часть утилит, которая работает "под капотом" для обеспечения приятного и уютного UX на вашем localhost-е.
| |
|
|
2.34, пох. (?), 18:39, 19/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Какие же вы упортые, пользователи x86. Вот в процах от IBM на
пользователи фон-неймановской архитектуры, вы хотели сказать? Догадаетесь, где сейчас все остальные архитектуры?
Правильно - в музее, рядом с вычислительной машиной Бэбиджа и памятью с троичной системой.
> аппаратном уровне есть запрет выделения памяти в режиме WX (одновременно для
очередной полуработающий костыль, это, конечно, прекрасно.
| |
|
|