В Packagist (https://packagist.org), крупнейшем репозитории пакетов на языке PHP, ежемесячно обслуживающем более 400 млн загрузок и по умолчанию применяемом в пакетной менеджере Composer, выявлена (https://justi.cz/security/2018/08/28/packagist-org-rce.html) критическая уязвимость, позволяющая выполнить код на сервере проекта через передачу специально оформленных значений в форму добавления нового пакета.Уязвимость вызвана отсутствием должной проверки передаваемых значений перед их обработкой в shell-скриптах. В частности, для выполнения произвольных shell-команд в текстовое поле с URL репозитория добавляемого проекта достаточно было ввести строку вида "$(код)". На стороне сервера данный URL передаётся в качестве аргумента при вызове команд git, p4, svn и hg. Для git и hg выполняется экранирование строки кавычками, но для p4 (Perforce) и svn (Subversion) строка передаётся как есть, например, при вводе "$(sleep 1)" будет запущена команда "svn info --non-interactive $(sleep 1)". Разработчики Packagist уже исправили (https://github.com/composer/composer/commit/bf125295df9da84c...) проблему, добавив экранирование при помощи вызова ProcessExecutor::escape() (https://github.com/composer/composer/blob/837ad7c14e8ce36429...).
К сожалению халатное отношение к безопасности присуще разработчикам многих современных репозиториев пакетов, что ставит под вопрос сохранение целостности пакетов в подобных системах. Например, выявивший проблему исследователь безопасности в прошлом году обнаружил похожую проблему в RubyGems (https://www.opennet.ru/opennews/art.shtml?num=47370), позволяющую выполнить код на сервере RubyGems.org при загрузке специально оформленного gem-пакета, а также продемонстрировал возможность (https://www.opennet.ru/opennews/art.shtml?num=47574) запуска своего кода на некоторых зеркалах NPM и нашёл способ (https://python-security.readthedocs.io/pypi-vuln/index-2017-...) удаления произвольных файлов из репозитория PyPI. Исследователь также выявил уязвимость (https://justi.cz/security/2018/05/23/cdn-tar-oops.html) в применяемой в NPM сети доставки контента, которая позволяла осуществить подстановку любого JavaScript-кода.URL: https://justi.cz/security/2018/08/28/packagist-org-rce.html
Новость: https://www.opennet.ru/opennews/art.shtml?num=49198
Загадка: что общего у дешёвого китайского роутера и крупнейшего репозитория пакетов на языке PHP?
Голая жопа торчащая в интернет
Ну вот, мироздание опять пришло в равновесие. А то непорядок, сайт на PHP был, а инъекции нет.
> Разработчики Packagist уже исправили проблему, добавив экранирование при помощи вызова ProcessExecutor::escape().Прям бальзам. Типичные пыхеры, с типичным "решением", хоть кол на голове теши.
То есть типичных рубистов и питонщиков мы игнорим, а пыхари-то козлы налажали..
Про js даже говорить нет смысла, но козлы все равно пыхари..
Не твоя вот и бесишся)
Как скажешь. Веб дерьмо и дерьмом останется. Все кто пишут для веба нелюди. Так лучше?
Согласно концепции web2.0 ты сейчас тоже пишешь "для веба". Нежнее надо быть, Анон!
Хотя комментарии содержащие слово "все" можно удалять неглядя, ибо 98% их есть чушь.
> То есть типичных рубистов и питонщиков мы игнорим, а пыхари-то козлы налажали..Питонщиков, слава богу, приучили не пользоваться system и передавать аргументы массивом в exec-like колы.
да-да, фильтровать untrusted data не надо, за вас позаботится массив аргументов.(потом они удивляются, что ж это тот же hg такой "незащищенный", ну надо же - мы передали в параметре кучу мусора, а он, гад такой, его взял и проинтерпретировал - а то и дальше передал, опять же в шелл. А он ни разу и не рассчитывал на подобное.)
> да-да, фильтровать untrusted data не надо, за вас позаботится массив аргументов.Я такого не говорил. И фильтровать надо, и передавать массивом. Безопасности много не бывает.
> Разработчики Packagist уже исправили проблему, добавив экранированиеФееричный фикс. Не удивлюсь, если они до сих пор не видят никаких проблем в самом использовании system()...
* в самом использовании php
А что с PHP не так?
Мне правда интересно.
мне не менее интересно, что не так с system(), если, конечно, не тянуть в параметры любой мусор, полученный из веба.
> мне не менее интересно, что не так с system()Вот ты лалка, а таким спецом выставлялся, прям гуру админства и проектирования сложных надежных систем. Для безопасного вызова внешних бинарников есть семейство функций exec*, которые позволяют не заботится об экранировании вообще и решить проблему принципиально.
Да тут 99% такие и 99% не знают, как GNU расшифровывается.
Зато вы, как узнали, сразу илитой себя ощутили, да?
> как GNU расшифровывается.так оно у тебя ещё и зашифровано?!!
> Для безопасного вызова внешних бинарников есть семейство функций exec*, которые позволяют не
> заботится об экранировании вообще и решить проблему принципиальнообалдеть.
Нет, дружище, это не решение проблемы. Это признание твоего неумения программировать, и перекладывание ее решения на других. Причем оно закрывает один узкий сегмент этой уязвимости, оставляя все остальные нараспашку, да еще и при ложной уверенности что ты сделал все правильно и можно уже не проверять данные из внешних источников. Молодец, так держать.
И нет, надо не экранировать, а фильтровать.
P.S. до кучи, еще один такой же звоночек - использование sn/strn вместо s/str - в надежде что уж тут-то буфер точно не переполнится.
> Это признание твоего неумения программировать, и перекладывание ее решения на других.Ребята из Drupal могут много рассказать про их надежную многоуровневую фильтрацию.
в смысле? У них ее отродясь как раз и не было - фильтруют где попало и когда попало - с весьма предсказуемым результатом.Причем в основных частях все сделано уже почти правильно (за миллион итераций с remote exec каждый раз), но, поскольку это каждый раз делалось для конкретного случая, а не общий интерфейс предусмотрен - оно каждый раз оказывается забыто в очередном новом месте ;-)
Не говоря уже про авторов плагинов, которые велосипед изобретают каждый раз заново. Потому что опять же нет готового api для них.
кстати, я тормоз - пишу про php, думаю про си.
(впрочем, кажется, автор исходной фигни вообще не в теме)php'шный exec() ни разу не обертка вокруг системного, он не имеет отдельного массива аргументов, и от system отличается только тем, что system() возвращает stdout обратно в вызывающий php, если ты собираешься его разглядывать или юзеру вывести прямо в браузер. Exec аккуратно складывает его в массив или просто выбрасывает, если не подставить.
Например, накладные расходы, связанные с запуском внешней программы, которых можно было бы избежать, если для тех же целей подвязать сишную либу (которая, собственно говоря, и выполняет работу) и дёргать её внутри интерпретатора.
Если честно, я хз, предусмотрено ли в php такое.
> Если честно, я хз, предусмотрено ли в php такое.предусмотренно, конечно, только если тебе надо из пехепе запустить, как тут, svn или hg - ты будешь писать враппер для svnlib, а для hg, который на пихоне - изобретешь его с нуля заново? ;-)
А почему бы и нет? Если на сайт заходят в день полтора анонимуса, можно и через system вызывать, а если нагрузка высокая, то на каждый запрос запускать процесс - это уже непозволительное расточительство, тут уже стОит озаботиться каким-то более эффективным способом.
Можно было бы заморочится в систему типов, введя безопасные и небезопасные строки. Вот константа - безопасна, так как не подвержена инъекции. А вот $_GET опасен. Складываем безопасную с опасной - получаем опасную. При таком подходе инхекций не было бы, так как у говнокодеров сайт просто падал бы с ошибкой.Впрочем в пыхе и более простые вещи поломаны, о чём можно говорить?
Хипсталюбители тянуть всё автоматом из *овнореп опять страдают. Ну удивительно же?
Вы не поверите, но "тянуть автоматом из*овнореп" - это единственный путь, общий для ПО на всех языках. Если у нужной вам программы прописаны зависимости "либа N из репы X" - вытянете, никуда не денетесь.
Окей, корректировочка: тянуть код автоматом из слабо верифицированных реп. Дальше хлебнуть смузи и ждать следующего ахтунга.
Что, в принципе, тоже вполне себе модель разработки, имеющая доказанную примерами экономическую эффективность. Если не впадать в крайности, то по ней большая часть софта и пишется. Ну по крайней мере, из того, что где-то запущен и генерирует денежную выгоду, а не существует в умах идеалистов, не продвинувшихся дальше филигранного оттачивания идей в своём воображении.
кек, трындеть все горазды, а вы бы лучше код свой показали
> К сожалению, халатное отношение к безопасности присуще разработчикам многих современных репозиториев пакетов, что ставит под вопрос возможность компрометации подобных систем злоумышленниками.Звучит так, как будто иметь возможность компрометации это ожидаемо, да вот баг мешает этому.
видимо это нужно понимать как "при таком раздолбайстве со стороны разработчиков многих современных репозиториев пакетов злоумышленникам становится скучно и обидно, и они в слезах идут ломать виндовс"
а потом сраться в комментариях о гендере и прочем sjw