В поставляемом в составе 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
Новость: http://www.opennet.ru/opennews/art.shtml?num=46854
Опыт ImageMagick ничему не учит?
>$archive $filenameMendel Cooper их уже не спасет.
Прикольный патч. Не осилили исправить и просто выпилили поддержку формата.
А как исправить-то? Судя по ману, у tar'а нет ключа конца опций (--).
http://libarchive.org/
> http://libarchive.org/https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libarchive
18 дыр только за прошлый год.
> А как исправить-то? Судя по ману, у tar'а нет ключа конца опций (--).Зато есть, например, опции -T и --null. Почему не скормить ему имя файла через пайп?
> А как исправить-то? Судя по ману, у tar'а нет ключа конца опций
> (--).Есть есть...
У кого есть? У GNU tar? У BSD tar? Или ещё у какой-то из множества реализаций?
tar ... < inputfile > outputfile
И правильно сделали. Это просмоторщик, а не архиватор.
Ну обычно hot-fix так и делают. Проще временно отключить фичу, если она некритична и фикс нужен серьёзный, и сделать нормальный патч, чем сразу кидаться и патчить, рискуя наделать других глюков.
> для извлечения каждого изображения в Evince запускается команда "tar -xOf $archive $filename"Oчередная победа святого юниксвея.
Слишком толсто.
Почему же? Уж сколько раз твердили миру, что все эти 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. Мельчают люди.
> не позволяют пересмотреть ситуацию и придумать лучшийТак и нельзя придумать ничего лучше.
Угу. Unix Way пора переименовать в Unix Dead End. Развиваться больше некуда. Разве что рендеринг шрифтов сделать искаропки.
Не знаю как на счёт дальнейшего развития, но за dead end (тупик) плюсанул.
> что все эти system(3)По умолчанию им никто и не пользуется, скажу тебе по секрету, это даже не в стандартах С. Используют ядерные fork(), posix_spawn(), clone(), но никак не system().
>> что все эти system(3)
> По умолчанию им никто и не пользуется, скажу тебе по секрету, это
> даже не в стандартах С. Используют ядерные fork(), posix_spawn(), clone(), но
> никак не system().Ну, во-первых, наверное, всё же не столько этот список функций важен в данном контексте, а таки execve? Ведь именно криво подготовленные аргументы для execve создают уязвимости?
А, во-вторых, какая разница, что именно они используют? Что бы это ни было, оно ничего не понимает в аргументах командной строки и позволяет программисту исподтишка совершать невероятные глупости.
> Ну, во-первых, наверное, всё же не столько этот список функций важен в данном контексте, а таки 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. Просто по другому не придумали ничего. Предложи свой вариант.
> А, во-вторых, какая разница, что именно они используют? Что бы это ни было, оно ничего не понимает в аргументах командной строки и позволяет программисту исподтишка совершать невероятные глупости.
В любом языке можно совершить такие глупости, которые потом аукнутся. Для этого существуют аудиты кода, и они нужны любому языку программирования. Человек не машина, он может ошибаться. А вот если ты не знаешь брода лезешь в воду, то лучше иди ещё подучись, прежде чем какие-либо серьёзные вещи писать. Например, можно посмотреть чужую реализацию.
> Абсолютно разные вызовы, делают абсолютно разное.Ну и зачем же _ты_ их сюда приплёл? В любом случае, так или иначе, запуск происходит через вызов execve. Хоть system() используй, хоть fork()+exec*(), хоть posix_spawn().
> А, во-вторых, какая разница, что именно они используют? Что бы это ни
> было, оно ничего не понимает в аргументах командной строки и позволяет
> программисту исподтишка совершать невероятные глупости.Угу, только проблема не в этом, а в том, как tar по сугубо историческим причинам обрабатывает свои аргументы. Перепиливали-перепиливали его, да недоперепилили. Из последней версии POSIX его вместе с прочими допотопными архиваторами, кстати, вообще выкинули, заменив на pax.
>> что все эти system(3)
> По умолчанию им никто и не пользуется, скажу тебе по секрету, это
> даже не в стандартах С. Используют ядерные fork(), posix_spawn(), clone(), но
> никак не system().У win кстати метод в стиле system...
> У win кстати метод в стиле system...Потому что NT следует POSIX, внезапно, да?
system(), если что, нестандартная функция. Ну так, на будущее.
Функция стандартной библиотеки C, прописанная в стандарте ISO/IEC, нестандартна? Вот это новости!
>> что все эти system(3)
> По умолчанию им никто и не пользуется, скажу тебе по секрету, это
> даже не в стандартах С.Вот как раз system(3) — в стандарте C.
> Используют ядерные fork(), posix_spawn(), clone(), но
> никак не system().А fork() и posix_spawn() есть только в POSIX. clone() же вообще нестандартная и непереносимая штука.
> тут ещё C гадит как язык: на нём, я боюсь, не получится действительно красивого API -- то что я выше написал можно через препроцессор раскрыть и получить результат, но там могут начаться проблемы с тем, как макрос или код им сгенерённый определят была ли какая-то опция упомянута или нет: в C ведь нет ни хаскельного Maybe, ни rust'ового Option. А если не на C писать -- дык не юниксвейно же: юниксвей признаёт только C'шный взгляд на API/ABI со всеми их ограничениямиТы ещё скажи, что у asm сплошные ограничения. Ограничения только в твоей глупой голове и твоих питонах, кстати, тоже.
>> тут ещё C гадит как язык: на нём, я боюсь, не получится действительно красивого API -- то что я выше написал можно через препроцессор раскрыть и получить результат, но там могут начаться проблемы с тем, как макрос или код им сгенерённый определят была ли какая-то опция упомянута или нет: в C ведь нет ни хаскельного Maybe, ни rust'ового Option. А если не на C писать -- дык не юниксвейно же: юниксвей признаёт только C'шный взгляд на API/ABI со всеми их ограничениями
> Ты ещё скажи, что у asm сплошные ограничения. Ограничения только в твоей
> глупой голове и твоих питонах, кстати, тоже.С асмом связываться без хорошего препроцессора можно только программируя микроконтроллеры. А если взять хороший препроцессор к асму, то получится что-нибудь в стиле rust.
> что-нибудь в стиле rust.Ржавчина ржавая с самого начала, гарбедж коллектор, уродливый синтаксис, и "momory safety" только за счёт того, что убрали указатели? Не смешите мои мокасины. Чудес не бывает, всё равно, если писать криво, будут уязвимости даже в Java. Пока что язык новый, поэтому сообщений об узявимостях нет, да и используют его 1.5 проекта. Как станет таким же популярным как С++, сразу куча уязвимостей, недоработок в архитектуре вылезет. А потом, года через два, объявят, что Rust устарел и мы пишем новый Безопасный(C)(TM) язык программирования!
В любом случае, уязвимости в SoC никто не отменял. Один IME чего стоит.
>> rust.
> гарбедж коллектор
> убрали указателиШо?
> Ржавчина ржавая с самого начала, гарбедж коллектор, уродливый синтаксис, и "momory safety" только за счёт того, что убрали указатели?Совсем упоролись эти жабоскриптчики.
В ржавом сборщик мусора ещё в самых ранних альфа версиях выпилили. А указатели никто не убирал.
> Ты ещё скажи, что у asm сплошные ограничения. Ограничения только в твоей
> глупой голове и твоих питонах, кстати, тоже.Ну, я скажу.
А ты, как эксперт опеннета по компиляторам и ассемблерам, расскажи незнающим, как ты на _практике_ будешь в асме колбэки на основе замыканий или генерики делать.
И почему во всех сохранившихся диалектах асма, которые не задумывались как бэкэнд, можно целую кучу высокоуровневых вещей найти, впрлоть до макросов?
> и пускай библиотека консультируется с базой данных команд и соображает как раскрыть макрос run_programordu, проблема в том, что базы terminfo создать вообще говоря возможно: ты выбираешь конечное число наиболее распространённых терминалов, обеспечиваешь к ним унифицированный интерфейс, а затем не спеша добавляешь менее распространённые.
В случае же с базой всех возможных команд, это уже задача принципиально другого уровня:
Во-первых, необходимо регистрировать каждую команду в системе при установке, кто должен это делать? Разработчик программы? Мейнтейнер?
Во-вторых, необходимо перед вызовом каждой программы проверять корректность её аргументов по базе, и не давать ей запуститься, если параметры не правильные. И это необходимо в рантайме, хотя бы потому, что существуют языки shell. База будет большой. Сильно увеличится время запуска.
В-третьих, даже если написать типизированный shell с выводом типов по хиндли-милнеру, он будет конечно безопаснее, но пользоваться им будет крайне неудобно. Почему? Да хотя бы потому что 100500 программ заточены под возврат ошибки не в виде ocaml-овских option или result, но через возврат int-а, и нам придётся все вызовы оборачивать во что-то эдакое.
В-четвёртых, что вы с этой вашей базой будете делать с программами, в которых аргументы представляют собой язык? В аргументах которых можно задавать другие команды? Ну тот же "bash -c <command>", тот же "find ... -exec <command>"? Это ж пипец, предусмотреть все случаи.
В-пятых, не все команды принимают аргументы, следуя рекомендациям posix. tar, unrar, например... Как эти программы в базу вносить?Вы предлагаете создать базу программ, но это лишь способ перенести проверку с программы на какой-то внешний механизм. Спрашивается, зачем? При разработке Unix долго думали, как это сделать, и как видите, оставили это на усмотрение разработчиков. И это самый правильный путь, потому что программ великое множество, и список их постоянно пополняется, так что за всеми не уследить.
Все эти проблемы возникают, если пытаться покрыть абсолютно все потребности всего софта. Если же ограничиться конкретным набором (описанным в POSIX или Singe Unix, например) - всё проще, и это покроет большой процент реального использования. Для остального - ругающиеся линтеры и соответствующие стандарты качества, и подобные баги будут вытеснены куда=то на обочину цивилизованного программирования.
Для find и подобных определить отдельный "выхываемый" аргумент - тоже можно.Хотя as for me - оно того не стоит, если уж связываться с новым API и кучей работы - надо дальше идти, и вводить типизацию параметров и хотя бы внятную стандартную сериализацию в стандартном вводе/выводе, если не типизацию с рефлексией.
> В случае же с базой всех возможных команд, это уже задача принципиально
> другого уровня:
> Во-первых, необходимо регистрировать каждую команду в системе при установке, кто должен
> это делать? Разработчик программы? Мейнтейнер?Для начала разработчик программы. Со временем мейнтейнеры дистрибутивов начнут помогать. А в далёком будущем автор любой шелл-утилиты будет создавать к ней файлик с описанием опций.
> Во-вторых, необходимо перед вызовом каждой программы проверять корректность её аргументов
> по базе, и не давать ей запуститься, если параметры не правильные.
> И это необходимо в рантайме, хотя бы потому, что существуют языки
> 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 тратить своё время на выяснение всех подводных камней, если можно проделать это единожды и дать этому программисту готовый код, обходящий все подводные камни?
Я тебе объясню на пальцах что ты думило
Не в бровь, а в глаз!
для манжары никаких апдэйтов тоже не приходило.
2017й год на дворе, а в линуксе при просмотре сайтов exec используют. И эти люди потом ещё катят бочку на Винду...
2017й год на дворе, а в винде обновление офисного пакета требует перезагрузки всей системы. И эти люди потом ещё катят бочку на Линукс...
И что же мешает всю эту дрянь запускать под ограничивающим профилем AppArmor или SELinux?
Очень просто AppArmor и SELinux направлены на серверное применение.
Отлаживать их работу с десктопным софтом никому особо не охота.
Rust не учит жизни.
Гномоящеры как всегда лохонулись на пустом месте. Проблемы mplayer никого не учат, все кругом слепые? Тот же smplayer до сих пор парсит регулярками выхлоп работы mplayer позорище. Ладно хоть существует libmpv.
Возьми и научи их как правильно. Некому контрибьютить же, от того имеем что имеем.
Не-не, не надо портить smplayer! Пусть своё напишет.
Никто не запрещает форкать же.Да и этих плееров/плееров-обёрток – хоть пруд пруди, но действительно качественных – не напасёшься.
Склепал proof of concept. Действительно работает. Достаточно взять валидный jpg, дать ему указанное в новости имя и запаковать в tar с именем, заканчивающимся на .cbr.
все программисты, использующие консольные утилиты вместо либ, если такие есть для языка, профнепригодны.
Все программисты, считающие, что нельзя в программах использовать консольные утилиты, вчерашние или сегодняшние виндуzятники. А в юниксах это такой же нормальный способ повторного использование кода, как и линковка с библиотеками, и все юниксовые IPC как раз под это заточены.
#>>вместо либ, если такие есть для языка, профнепригодны.
> Все программисты, считающие, что нельзя в программах использовать консольные утилиты,
> вчерашние или сегодняшние виндуzятники. А в юниксах это такой же нормальный
> способ повторного использование кода, как и линковка с библиотеками, и все
> юниксовые IPC как раз под это заточены....точн, слыхал я тех погромистов - про ""удобство"" libsystemd0 и неосиляние /bin/bash. И про профнепригодность и "вон из профессии". Не буду погромистом!
Хм, а я в гноме пользуюсь qpdfview, evince тормоз.