Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	+/–
Сообщение от opennews (??) on 14-Июл-17, 22:23
В поставляемом в составе GNOME просмотрщике документов Evince (https://wiki.gnome.org/Apps/Evince) выявлена уязвимость (https://bugzilla.gnome.org/show_bug.cgi?id=784630) (CVE-2017-1000083 (https://security-tracker.debian.org/tracker/CVE-2017-1000083)), которая может привести к выполнению кода злоумышленника при открытии специально оформленного файла в формате CBT (используется для комиксов). Проблема вызвана ошибкой в реализации обработчика comic book, входящего в состав evince. Уязвимость также проявляется (https://github.com/mate-desktop/atril/blob/master/backend/co...) в Atril (форк Evince, развиваемый проектом MATE) и Xreader (форк Atril от проекта Linux Mint). Особую опасность представляет то, что  уязвимость может быть эксплуатирована без явного открытия файлов пользователем - в процессе автоматического построения пиктограмм с эскизами для новых файлов, т.е. для эксплуатации достаточно просмотреть список файлов в файловом менеджере или вставить носитель.  Более того, можно организовать (https://www.opennet.ru/opennews/art.shtml?num=45543) загрузку вредоносного файла и запуск evince-thumbnailer незаметно от пользователя при открытии специально оформленной web-страницы в  браузерах Chrome и Epiphany. Проблему усугубляет то, что evince-thumbnailer запускается без применения sandbox-изоляции. CBT-файл представляет собой tar-архив, в котором размещена упорядоченная коллекция  изображений. В процессе просмотра комиксов для извлечения каждого изображения в Evince запускается команда "tar -xOf $archive $filename". Имена файлов перед запуском экранируются кавычками. Атакующий может поместить в архив картинку  с именем, начинающимся с символов  "--" и при запуске tar для извлечения данного файла имя этого файла будет обработано как опция командной строки. Таким образом, поместив в архив файл с именем "--checkpoint-action=exec=bash -c 'touch ~/covfefe.evince;'.jpg", можно добиться выполнения команды touch. По аналогии можно организовать выполнение любого кода на shell. Разработчики GNOME уже выпустили патчи (https://bugzilla.gnome.org/attachment.cgi?id=355499&action=diff) для веток gnome-3-20, gnome-3-22 и gnome-3-24. Уязвимость пока остаётся неисправленной в Debian (https://security-tracker.debian.org/tracker/CVE-2017-1000083), RHEL (http://www.vuxml.org/freebsd/) и FreeBSD (http://www.vuxml.org/freebsd/).  Разработчики SUSE сформировали (https://bugzilla.novell.com/show_bug.cgi?id=CVE-2017-1000083) обновление для Tumbleweed, SLE12, SLE12 SP2, openSUSE Leap 42.2 и 42.3. Обновления также уже выпущены для Ubuntu (https://www.ubuntu.com/usn/usn-3351-1/) и  Fedora Linux (https://bugzilla.redhat.com/show_bug.cgi?id=1470661). В качестве обходного пути защиты рекомендуется временно отключить evince-thumbnailer (удалить /usr/share/thumbnailers/evince.thumbnailer) и не открывать непроверенные файлы в формате CBT. URL: https://bugzilla.gnome.org/show_bug.cgi?id=784630 Новость: https://www.opennet.ru/opennews/art.shtml?num=46854
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

2. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	+2 +/–
Сообщение от Аноним (??) on 14-Июл-17, 23:36
Опыт ImageMagick ничему не учит?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	+/–
Сообщение от Аноним (??) on 15-Июл-17, 00:04
>$archive $filename Mendel Cooper их уже не спасет.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	+/–
Сообщение от Аноним (??) on 15-Июл-17, 00:15
Прикольный патч. Не осилили исправить и просто выпилили поддержку формата.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	6. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	+/–
	Сообщение от Аноним (??) on 15-Июл-17, 00:31
	А как исправить-то? Судя по ману, у tar'а нет ключа конца опций (--).
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	7. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	–1 +/–
	Сообщение от pkunk (ok) on 15-Июл-17, 00:35
	http://libarchive.org/
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	9. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	–1 +/–
	Сообщение от Аноним (??) on 15-Июл-17, 00:45
	> http://libarchive.org/ https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libarchive 18 дыр только за прошлый год.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	8. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	+5 +/–
	Сообщение от Аноним (??) on 15-Июл-17, 00:41
	> А как исправить-то? Судя по ману, у tar'а нет ключа конца опций (--). Зато есть, например, опции -T и --null. Почему не скормить ему имя файла через пайп?
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	18. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	+/–
	Сообщение от Анонимный Алкоголик (??) on 15-Июл-17, 08:17
	> А как исправить-то? Судя по ману, у tar'а нет ключа конца опций > (--). Есть есть...
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	27. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	–1 +/–
	Сообщение от Аноним (??) on 15-Июл-17, 10:02
	У кого есть? У GNU tar? У BSD tar? Или ещё у какой-то из множества реализаций?
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	62. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	+/–
	Сообщение от Anonim (??) on 18-Июл-17, 10:23
	tar ... < inputfile > outputfile
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	25. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	–4 +/–
	Сообщение от Вы забыли заполнить поле Name on 15-Июл-17, 09:27
	И правильно сделали. Это просмоторщик, а не архиватор.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	26. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	+7 +/–
	Сообщение от llolik (ok) on 15-Июл-17, 09:51
	Ну обычно hot-fix так и делают. Проще временно отключить фичу, если она некритична и фикс нужен серьёзный, и сделать нормальный патч, чем сразу кидаться и патчить, рискуя наделать других глюков.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

5. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	–3 +/–
Сообщение от Аноним (??) on 15-Июл-17, 00:27
> для извлечения каждого изображения в Evince запускается команда "tar -xOf $archive $filename" Oчередная победа святого юниксвея.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	10. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	+1 +/–
	Сообщение от Аноним (??) on 15-Июл-17, 01:34
	Слишком толсто.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	11. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	+/–
	Сообщение от Ordu (ok) on 15-Июл-17, 05:34
	Почему же? Уж сколько раз твердили миру, что все эти system(3) до добра не доводят. Но традиции Unix Way не позволяют пересмотреть ситуацию и придумать лучший API. Юниксовые программисты потеряли запал и ни на что не годны. Вот есть совершенно бессистемно "спроектированный" исторический мусор терминала, со всеми этими esc-последовательностями, вендорскими расширениями, отсутствием стандартов и вообще беда. Но были люди в наше время, запилили termcap, terminfo, curses... Создали базу данных терминалов -- terminfo. Это не сняло всех проблем, но, по-крайней мере, стало возможным использование множества различных капабилитей разных терминалов, без необходимости запариваться при этом на совместимость с разными вендорами. Были люди в наше время. Но сегодня богатыри перевелись и уже нет у них запала запилить костылик a la terminfo для запуска команд. Создать базу данных разных команд, для каждой команды список типизированных аргументов (бинарная опция --help, перечислимая опция --codec=... со списком возможных значений, имя файла (существующего, не существующего, доступного за запись...), строка,...), написать библиотечку, которая будет в рантайме проверять аргументы, форматировать их так, чтобы программа не восприняла бы имя файла за ещё одну опцию, предоставить API для всего этого, чтобы программер писал бы что-нибудь типа: run_program(tar, {.short_options_batch="-xOf", .archive=archive, .filename=filename}) и пускай библиотека консультируется с базой данных команд и соображает как раскрыть макрос run_program, чтобы сгенерить код, который будет генерить строчку для system(3), которая будет делать именно то, что задумано программистом, а не произвольные вещи, определяемые содержимым переменных archive и filename. Но для юниксвея сегодня традиции важнее всего остального и отказываться от system никак нельзя. Впрочем, тут ещё C гадит как язык: на нём, я боюсь, не получится действительно красивого API -- то что я выше написал можно через препроцессор раскрыть и получить результат, но там могут начаться проблемы с тем, как макрос или код им сгенерённый определят была ли какая-то опция упомянута или нет: в C ведь нет ни хаскельного Maybe, ни rust'ового Option. А если не на C писать -- дык не юниксвейно же: юниксвей признаёт только C'шный взгляд на API/ABI со всеми их ограничениями. Хотя, во всяких там python'ах, которые действительно позволяют получить приятный API для таких вещей (именованные аргументы функций, например, очень уместны для этого), почему-то все так же продолжают пользоваться system. Мельчают люди.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	12. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	+/–
	Сообщение от Аноним (??) on 15-Июл-17, 06:39
	> не позволяют пересмотреть ситуацию и придумать лучший Так и нельзя придумать ничего лучше.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	13. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	–6 +/–
	Сообщение от Ordu (ok) on 15-Июл-17, 06:44
	Угу. Unix Way пора переименовать в Unix Dead End. Развиваться больше некуда. Разве что рендеринг шрифтов сделать искаропки.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	38. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	–4 +/–
	Сообщение от Аноним (??) on 15-Июл-17, 12:56
	Не знаю как на счёт дальнейшего развития, но за dead end (тупик) плюсанул.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	14. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	+1 +/–
	Сообщение от Аноним (??) on 15-Июл-17, 07:13
	> что все эти system(3) По умолчанию им никто и не пользуется, скажу тебе по секрету, это даже не в стандартах С. Используют ядерные fork(), posix_spawn(), clone(), но никак не system().
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	16. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	+1 +/–
	Сообщение от Ordu (ok) on 15-Июл-17, 07:54
	>> что все эти system(3) > По умолчанию им никто и не пользуется, скажу тебе по секрету, это > даже не в стандартах С. Используют ядерные fork(), posix_spawn(), clone(), но > никак не system(). Ну, во-первых, наверное, всё же не столько этот список функций важен в данном контексте, а таки execve? Ведь именно криво подготовленные аргументы для execve создают уязвимости? А, во-вторых, какая разница, что именно они используют? Что бы это ни было, оно ничего не понимает в аргументах командной строки и позволяет программисту исподтишка совершать невероятные глупости.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	21. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	–1 +/–
	Сообщение от Аноним (??) on 15-Июл-17, 08:32
	> Ну, во-первых, наверное, всё же не столько этот список функций важен в данном контексте, а таки execve А может ты почитаешь, перед тем как глупости молоть? execve()  executes  the program pointed to by filename. clone() creates a new process, in a manner similar to fork(2). Unlike  fork(2),  clone()  allows  the child process to share parts of its execution context with the calling process, such as the memory space, the table of file descriptors, and  the  table  of  signal handlers. fork()  creates  a new process by duplicating the calling process. The posix_spawn() and posix_spawnp() functions are used to create a new child process that executes a specified file. Абсолютно разные вызовы, делают абсолютно разное. Кстати, если ты думаешь, что в NT по другому, ты даже не представляешь, как ты ошибаешься, там всё тот же posix. Просто по другому не придумали ничего. Предложи свой вариант. > А, во-вторых, какая разница, что именно они используют? Что бы это ни было, оно ничего не понимает в аргументах командной строки и позволяет программисту исподтишка совершать невероятные глупости. В любом языке можно совершить такие глупости, которые потом аукнутся. Для этого существуют аудиты кода, и они нужны любому языку программирования. Человек не машина, он может ошибаться. А вот если ты не знаешь брода лезешь в воду, то лучше иди ещё подучись, прежде чем какие-либо серьёзные вещи писать. Например, можно посмотреть чужую реализацию.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	41. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	+/–
	Сообщение от Аноним (??) on 15-Июл-17, 13:22
	> Абсолютно разные вызовы, делают абсолютно разное. Ну и зачем же _ты_ их сюда приплёл? В любом случае, так или иначе, запуск происходит через вызов execve. Хоть system() используй, хоть fork()+exec*(), хоть posix_spawn().
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	35. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	+/–
	Сообщение от Аноним (??) on 15-Июл-17, 11:39
	> А, во-вторых, какая разница, что именно они используют? Что бы это ни > было, оно ничего не понимает в аргументах командной строки и позволяет > программисту исподтишка совершать невероятные глупости. Угу, только проблема не в этом, а в том, как tar по сугубо историческим причинам обрабатывает свои аргументы. Перепиливали-перепиливали его, да недоперепилили. Из последней версии POSIX его вместе с прочими допотопными архиваторами, кстати, вообще выкинули, заменив на pax.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	20. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	+/–
	Сообщение от Анонимный Алкоголик (??) on 15-Июл-17, 08:28
	>> что все эти system(3) > По умолчанию им никто и не пользуется, скажу тебе по секрету, это > даже не в стандартах С. Используют ядерные fork(), posix_spawn(), clone(), но > никак не system(). У win кстати метод в стиле system...
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	22. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	–2 +/–
	Сообщение от Аноним (??) on 15-Июл-17, 08:33
	> У win кстати метод в стиле system... Потому что NT следует POSIX, внезапно, да?
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	23. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	–1 +/–
	Сообщение от Аноним (??) on 15-Июл-17, 08:35
	system(), если что, нестандартная функция. Ну так, на будущее.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	32. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	+2 +/–
	Сообщение от Аноним (??) on 15-Июл-17, 11:26
	Функция стандартной библиотеки C, прописанная в стандарте ISO/IEC, нестандартна? Вот это новости!
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	34. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	+1 +/–
	Сообщение от Аноним (??) on 15-Июл-17, 11:35
	>> что все эти system(3) > По умолчанию им никто и не пользуется, скажу тебе по секрету, это > даже не в стандартах С. Вот как раз system(3) — в стандарте C. > Используют ядерные fork(), posix_spawn(), clone(), но > никак не system(). А fork() и posix_spawn() есть только в POSIX. clone() же вообще нестандартная и непереносимая штука.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	15. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	–4 +/–
	Сообщение от Аноним (??) on 15-Июл-17, 07:17
	> тут ещё C гадит как язык: на нём, я боюсь, не получится действительно красивого API -- то что я выше написал можно через препроцессор раскрыть и получить результат, но там могут начаться проблемы с тем, как макрос или код им сгенерённый определят была ли какая-то опция упомянута или нет: в C ведь нет ни хаскельного Maybe, ни rust'ового Option. А если не на C писать -- дык не юниксвейно же: юниксвей признаёт только C'шный взгляд на API/ABI со всеми их ограничениями Ты ещё скажи, что у asm сплошные ограничения. Ограничения только в твоей глупой голове и твоих питонах, кстати, тоже.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	17. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	+/–
	Сообщение от Ordu (ok) on 15-Июл-17, 07:55
	>> тут ещё C гадит как язык: на нём, я боюсь, не получится действительно красивого API -- то что я выше написал можно через препроцессор раскрыть и получить результат, но там могут начаться проблемы с тем, как макрос или код им сгенерённый определят была ли какая-то опция упомянута или нет: в C ведь нет ни хаскельного Maybe, ни rust'ового Option. А если не на C писать -- дык не юниксвейно же: юниксвей признаёт только C'шный взгляд на API/ABI со всеми их ограничениями > Ты ещё скажи, что у asm сплошные ограничения. Ограничения только в твоей > глупой голове и твоих питонах, кстати, тоже. С асмом связываться без хорошего препроцессора можно только программируя микроконтроллеры. А если взять хороший препроцессор к асму, то получится что-нибудь в стиле rust.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	19. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	–4 +/–
	Сообщение от Аноним (??) on 15-Июл-17, 08:19
	> что-нибудь в стиле rust. Ржавчина ржавая с самого начала, гарбедж коллектор, уродливый синтаксис, и "momory safety" только за счёт того, что убрали указатели? Не смешите мои мокасины. Чудес не бывает, всё равно, если писать криво, будут уязвимости даже в Java. Пока что язык новый, поэтому сообщений об узявимостях нет, да и используют его 1.5 проекта. Как станет таким же популярным как С++, сразу куча уязвимостей, недоработок в архитектуре вылезет. А потом, года через два, объявят, что Rust устарел и мы пишем новый Безопасный(C)(TM) язык программирования! В любом случае, уязвимости в SoC никто не отменял. Один IME чего стоит.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	42. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	+3 +/–
	Сообщение от Аноним (??) on 15-Июл-17, 13:26
	>> rust. > гарбедж коллектор > убрали указатели Шо?
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	44. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	+4 +/–
	Сообщение от Anonim (??) on 15-Июл-17, 13:55
	> Ржавчина ржавая с самого начала, гарбедж коллектор, уродливый синтаксис, и "momory safety" только за счёт того, что убрали указатели? Совсем упоролись эти жабоскриптчики. В ржавом сборщик мусора ещё в самых ранних альфа версиях выпилили. А указатели никто не убирал.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	50. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	+2 +/–
	Сообщение от Аноним (??) on 15-Июл-17, 19:07
	> Ты ещё скажи, что у asm сплошные ограничения. Ограничения только в твоей > глупой голове и твоих питонах, кстати, тоже. Ну, я скажу. А ты, как эксперт опеннета по компиляторам и ассемблерам, расскажи незнающим, как ты на _практике_ будешь в асме колбэки на основе замыканий или генерики делать. И почему во всех сохранившихся диалектах асма, которые не задумывались как бэкэнд, можно целую кучу высокоуровневых вещей найти, впрлоть до макросов?
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	39. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	+1 +/–
	Сообщение от freehck (ok) on 15-Июл-17, 13:05
	> и пускай библиотека консультируется с базой данных команд и соображает как раскрыть макрос run_program ordu, проблема в том, что базы terminfo создать вообще говоря возможно: ты выбираешь конечное число наиболее распространённых терминалов, обеспечиваешь к ним унифицированный интерфейс, а затем не спеша добавляешь менее распространённые. В случае же с базой всех возможных команд, это уже задача принципиально другого уровня: Во-первых, необходимо регистрировать каждую команду в системе при установке, кто должен это делать? Разработчик программы? Мейнтейнер? Во-вторых, необходимо перед вызовом каждой программы проверять корректность её аргументов по базе, и не давать ей запуститься, если параметры не правильные. И это необходимо в рантайме, хотя бы потому, что существуют языки shell. База будет большой. Сильно увеличится время запуска. В-третьих, даже если написать типизированный shell с выводом типов по хиндли-милнеру, он будет конечно безопаснее, но пользоваться им будет крайне неудобно. Почему? Да хотя бы потому что 100500 программ заточены под возврат ошибки не в виде ocaml-овских option или result, но через возврат int-а, и нам придётся все вызовы оборачивать во что-то эдакое. В-четвёртых, что вы с этой вашей базой будете делать с программами, в которых аргументы представляют собой язык? В аргументах которых можно задавать другие команды? Ну тот же "bash -c <command>", тот же "find ... -exec <command>"? Это ж пипец, предусмотреть все случаи. В-пятых, не все команды принимают аргументы, следуя рекомендациям posix. tar, unrar, например... Как эти программы в базу вносить? Вы предлагаете создать базу программ, но это лишь способ перенести проверку с программы на какой-то внешний механизм. Спрашивается, зачем? При разработке Unix долго думали, как это сделать, и как видите, оставили это на усмотрение разработчиков. И это самый правильный путь, потому что программ великое множество, и список их постоянно пополняется, так что за всеми не уследить.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	43. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	+1 +/–
	Сообщение от Crazy Alex (ok) on 15-Июл-17, 13:27
	Все эти проблемы возникают, если пытаться покрыть абсолютно все потребности всего софта. Если же ограничиться конкретным набором (описанным в POSIX или Singe Unix, например) - всё проще, и это покроет большой процент реального использования. Для остального - ругающиеся линтеры и соответствующие стандарты качества, и подобные баги будут вытеснены куда=то на обочину цивилизованного программирования. Для find и подобных определить отдельный "выхываемый" аргумент - тоже можно. Хотя as for me - оно того не стоит, если уж связываться с новым API и кучей работы - надо дальше идти, и вводить типизацию параметров и хотя бы внятную стандартную сериализацию в стандартном вводе/выводе, если не типизацию с рефлексией.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	48. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	–1 +/–
	Сообщение от Ordu (ok) on 15-Июл-17, 18:14
	> В случае же с базой всех возможных команд, это уже задача принципиально > другого уровня: > Во-первых, необходимо регистрировать каждую команду в системе при установке, кто должен > это делать? Разработчик программы? Мейнтейнер? Для начала разработчик программы. Со временем мейнтейнеры дистрибутивов начнут помогать. А в далёком будущем автор любой шелл-утилиты будет создавать к ней файлик с описанием опций. > Во-вторых, необходимо перед вызовом каждой программы проверять корректность её аргументов > по базе, и не давать ей запуститься, если параметры не правильные. > И это необходимо в рантайме, хотя бы потому, что существуют языки > shell. База будет большой. Сильно увеличится время запуска. База будет большой, и что с того? До тех пор, пока программист вызывает команду известную на этапе компиляции, поиск по базе можно выполнить на этом же этапе компиляции. И большую часть проверок провести там же. Это даже с C возможно подчастую: компилятор может выполнять простенький код на этапе компиляции, с тем чтобы заменять код результатом его выполнения. Проверка трёх аргументов для tar, мне кажется, может быть выполнена в рантайме за время превосходящее время сисколлов fork/exec не более чем на порядок. А может быть даже быстрее -- сисколлы, с их переключением контекстов, вообще тормозные. > В-третьих, даже если написать типизированный shell с выводом типов по хиндли-милнеру, Ни о каком шелле я не говорил. Шелл и запускаемая программа как-то проверяют синтаксис командной строки и аргументов -- но этих проверок явно недостаточно. Речь о том, чтобы проверить аргументы ДО того, как они будут переданы в legacy шелл и legacy утилиту. Ошибки вида "Invalid file name starting with `--'" будут возникать в недрах библиотеки до того как будут выполнены fork и exec для запуска шелла или legacy утилиты. > В-четвёртых, что вы с этой вашей базой будете делать с программами, в > которых аргументы представляют собой язык? В аргументах которых можно задавать другие > команды? Ну тот же "bash -c <command>", тот же "find ... > -exec <command>"? Это ж пипец, предусмотреть все случаи. Эта проблему нельзя решить на 100% -- я согласен. Даже изобретение такого языка описания аргументов утилит для базы данных, который, с одной стороны, справится с 90% утилит, с другой стороны будет не слишком заморочным, потребует долгой возни. Это оптимизационная проблема, надо найти компромисс между простотой и гибкостью. Но я отмечу, что помимо декларативного описания аргументов в базе, возможно использовать ad hoc код для отдельных утилит, который будет особым образом работать с выбранной утилитой. Кроме того, задача не сделать так, чтобы любая осмысленная комбинация аргументов для любой утилиты была бы возможна, задача сделать так, чтобы была достижимой любая цель, ради которой вызывается утилита. У меня нет готового осмысленного примера, для пояснения этого, но в качестве слабоосмысленного примера: если мы не дадим способа объединять короткие опции в один аргумент, и если необходимо передать -jxf в команду, то будет переданы -j, -x, -f по отдельности, то это вполне допустимо. Ну и финально, в дополнение к safe API для вызова дать unsafe API для обхода такого рода случаев. Главное чтобы этот API был бы более геморройным для программиста и провоцировал бы его поискать обходные safe пути, которые выполнят все проверки. Может вовсе не обязательно запускать bash -c для достижения цели? > В-пятых, не все команды принимают аргументы, следуя рекомендациям posix. tar, unrar, например... > Как эти программы в базу вносить? Функционально, а не декларативно. Взять и написать функцию check_args_unrar(...). > Вы предлагаете создать базу программ, но это лишь способ перенести проверку с > программы на какой-то внешний механизм. Спрашивается, зачем? При разработке Unix долго > думали, как это сделать, и как видите, оставили это на усмотрение > разработчиков. И это самый правильный путь, потому что программ великое множество, > и список их постоянно пополняется, так что за всеми не уследить. Программ великое множество -- бесспорно. Но уследить за всеми возможно: мейнтейнеры дистрибутивов этим занимаются постоянно. Кроме того, этим могут заниматься сами разработчики программ. Написал новую утилиту? Создай запись к базе данных. Ну и финально, можно же взять и создать декларативный язык описания опций командной строки, который затем можно скомпилировать в декларации C, C++, в Python код, во всё что угодно ещё, и заодно компилировать его в описание для базы данных утилит. Иногда это можно сделать и без создания нового языка, но дополняя старый: если взять тот же argp.h и дополнить его описания аргументов ещё одним полем -- типом аргумента, то мы получим описание, которое можно легко и непринуждённо скомпилировать в то, что надо нам. > Вы предлагаете создать базу программ, но это лишь способ перенести проверку с > программы на какой-то внешний механизм. Спрашивается, зачем? Затем, что программа не может выполнить проверку полностью, в силу потери информации при передаче аргументов. Собственно, проверки того, что программа и так проверяет вовсе не обязательны. Главная задача -- это чтобы API вызова внешней программы позволял бы писать такой код вызова, который бы не делал ничего, что неочевидно из этого кода. Если я написал `tar filename', то должен быть вызван tar с аргументом-именем файла. Даже если filename -- это переменная содержащая строчку полученную в рантайме извне программы. Либо будет вызыван tar с аргументом-файлом, либо он не будет вызван, а вызывающий код получит код ошибки. Второе может быть, например, если tar невозможно вызвать с именем файла начинающегося с --, если tar любой аргумент начинающийся с -- трактует как опцию. То, что предлагает unix, требует от программиста делающего вызов system(3) выполнять все эти проверки каждый раз одну за другой, ничего не забывая, помня все подводные камни. Подводные камни общего случая, и подводные камни свойственные конкретной утилите, которую он вызывает. Помнить он естественно не помнит, потому вся надежда на то, что он внимательно и вдумчиво прочитает мануал к утилите, заметит там все возможные способы ошибиться, и напишет без ошибок. Ха-ха. Это каким же надо быть оптимистом, чтобы полагать, что хотя бы в 10% случаев код вызова внешней утилиты будет написан без ошибок с первого раза? И зачем нужно каждому программисту вызывающему tar тратить своё время на выяснение всех подводных камней, если можно проделать это единожды и дать этому программисту готовый код, обходящий все подводные камни?
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	37. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	–1 +/–
	Сообщение от Аноним (??) on 15-Июл-17, 12:18
	Я тебе объясню на пальцах что ты думило
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	29. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	–2 +/–
	Сообщение от Нанобот (ok) on 15-Июл-17, 10:23
	Не в бровь, а в глаз!
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

24. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	–1 +/–
Сообщение от Аноним (??) on 15-Июл-17, 08:38
для манжары никаких апдэйтов тоже не приходило.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

28. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	–4 +/–
Сообщение от Нанобот (ok) on 15-Июл-17, 10:22
2017й год на дворе, а в линуксе при просмотре сайтов exec используют. И эти люди потом ещё катят бочку на Винду...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	61. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	+1 +/–
	Сообщение от Аноним (??) on 17-Июл-17, 23:45
	2017й год на дворе, а в винде обновление офисного пакета требует перезагрузки всей системы. И эти люди потом ещё катят бочку на Линукс...
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

30. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	+/–
Сообщение от Аноним (??) on 15-Июл-17, 11:02
И что же мешает всю эту дрянь запускать под ограничивающим профилем AppArmor или SELinux?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	40. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	–1 +/–
	Сообщение от soarin (ok) on 15-Июл-17, 13:10
	Очень просто AppArmor и SELinux направлены на серверное применение. Отлаживать их работу с десктопным софтом никому особо не охота.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

49. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	–1 +/–
Сообщение от Аноним (??) on 15-Июл-17, 18:27
Rust не учит жизни.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

51. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	–2 +/–
Сообщение от Аноним (??) on 15-Июл-17, 21:49
Гномоящеры как всегда лохонулись на пустом месте. Проблемы mplayer никого не учат, все кругом слепые? Тот же smplayer до сих пор парсит регулярками выхлоп работы mplayer позорище. Ладно хоть существует libmpv.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	53. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	–2 +/–
	Сообщение от Аноним (??) on 16-Июл-17, 02:53
	Возьми и научи их как правильно. Некому контрибьютить же, от того имеем что имеем.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	55. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	+/–
	Сообщение от Аноним (??) on 16-Июл-17, 09:47
	Не-не, не надо портить smplayer! Пусть своё напишет.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	60. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	–1 +/–
	Сообщение от Аноним (??) on 16-Июл-17, 19:08
	Никто не запрещает форкать же. Да и этих плееров/плееров-обёрток – хоть пруд пруди, но действительно качественных – не напасёшься.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

54. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	+1 +/–
Сообщение от Аноним (??) on 16-Июл-17, 04:42
Склепал proof of concept. Действительно работает. Достаточно взять валидный jpg, дать ему указанное в новости имя и запаковать в tar с именем, заканчивающимся на .cbr.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

56. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	–2 +/–
Сообщение от Аноним (??) on 16-Июл-17, 11:49
все программисты, использующие консольные утилиты вместо либ, если такие есть для языка, профнепригодны.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	57. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	+3 +/–
	Сообщение от Аноним (??) on 16-Июл-17, 15:12
	Все программисты, считающие, что нельзя в программах использовать консольные утилиты, вчерашние или сегодняшние виндуzятники. А в юниксах это такой же нормальный способ повторного использование кода, как и линковка с библиотеками, и все юниксовые IPC как раз под это заточены.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	58. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	+1 +/–
	Сообщение от Andrey Mitrofanov on 16-Июл-17, 17:00
	#>>вместо либ, если такие есть для языка, профнепригодны. > Все программисты, считающие, что нельзя в программах использовать консольные утилиты, > вчерашние или сегодняшние виндуzятники. А в юниксах это такой же нормальный > способ повторного использование кода, как и линковка с библиотеками, и все > юниксовые IPC как раз под это заточены. ...точн, слыхал я тех погромистов - про ""удобство"" libsystemd0 и неосиляние /bin/bash.  И про профнепригодность и "вон из профессии".  Не буду погромистом!
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

59. "Уязвимость в GNOME Evince, позволяющая выполнить код при пос..."	–1 +/–
Сообщение от Аноним (??) on 16-Июл-17, 17:38
Хм, а я в гноме пользуюсь qpdfview, evince тормоз.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема