Приложения, запускающие сценарии в формате bat и cmd на платформе Windows при помощи штатных функций запуска процессов, подвержены уязвимости, позволяющей добиться выполнения своего кода в случае передачи при запуске аргументов без отдельного экранирования спецсимволов. Уязвимость получила кодовое имя BatBadBut и проявляется в приложениях, использующих стандартные библиотеки таких языков, как Rust, PHP, Node.js, Python, Ruby, Go, Erlang и Haskell...Подробнее: https://www.opennet.me/opennews/art.shtml?num=60964
А ещё остались люди, кто серваки на винде держит?
Это будет использоваться не на серваках, совсем не на серваках.
Вернее, подозреваю, давно используется не на серваках.
В mission critical сегменте куча винды.
Прям настолько жёстком?
Не, жесткое это mission impossible.
> В mission critical сегменте куча винды.Вот только на винде бы mission critical и делать, да...
> В mission critical сегменте куча винды.Пример Йорктауна так никого ничему и не научил...
О чём речь?
https://www.wired.com/1998/07/sunk-by-windows-nt/
> The source of the problem on the Yorktown was that bad data was fed into an application running on one of the 16 computers on the LAN. The data contained a zero where it shouldn't have, and when the software attempted to divide by zero, a buffer overrun occurred -- crashing the entire network and causing the ship to lose control of its propulsion system.Зачем проверять данные, лол.
Apache c PHP 5 под 98 виндой гоняю на ретропк, наполняю базу данных через Web-морду. Одновремено захожу с IE5 и смартфона. Если система тянет, пусть живет. Уникод поддерживается, через JSON-файлы можно осуществлять экспорт на продакшен под Linux.
Еще осталось очень много людей, а среди них каких только нет, есть даже такие, кто серваки на винде держит.
Печально, когда и если ещё и батнички живы... Такая махровая халтура и так долго прожила.Занятно. Но тоскливо.
> Уязвимость BatBadBut, затрагивающая стандартные библиотеки различных языков программированияПравильный заголовок будет "Уязвимость BatBadBut, затрагивающая стандартные библиотеки различных языков программирования в Windows"
Дело не в языках, а в супер надежной проприетарной системе (как нам завещал товарищ birdie)
> Дело не в языках, а в супер надежной проприетарной системе (как нам
> завещал товарищ birdie)Как хорошо что в линуксе нет башскиптов, которые могут и рут подарить, и обфуцировать код для бекдора и даже нафиг удалить все файлы юзеров!
Или есть?
При чем тут скрипты вообще?
> в Windows при использовании API CreateProcess аргументы оформляются в виде одной строкиЗыж
Вот взял и раст скриптами обозвал
Да так любой экзешник можно заставить cmd.exe вызвать.
И питонятины повсюду тоже нет.
> линуксе нет башскиптовВ линуксе даже и обход антивируса gmail из коробки стоит ,бггг
> башскиптов, которые могут и рут подаритьПосле ввода пароля рута.
> удалить все файлы юзеров!
Только те, с правами которых запущен процесс. А ты хотел бы вводить пароль пользователя при создании/удалении/перемещении каждого файла? ACL и sudoers тебе в руки. Но зачем? Может, просто ставить программы пакетником и не запускать всякую дрянь с файлопомоек, как принято в Винде?
>В Rust 1.77.2 в стандартную библиотеку добавлена дополнительная проверка, возвращающая ошибку при наличии в аргументе запускаемого сценария спецсимволов, которое невозможно гарантированно безопасно экранировать.Не понял, а что Rust ещё и в качестве интерпретатора используется?
> в Windows при использовании API CreateProcess аргументы оформляются в виде одной строкив Windows любой экзешник превращается в интерпретатор
Что, Fabric уже посчитали одной большой уязвимостью?
Мдее, Раст и иже с ними оказались дырявыми совсем не в том месте где ожидалось... Год назад говорил об этом. И количество этих дыр будут РАСТи..
> Проекты Python, Ruby, Go, Erlang и Haskell пока ограничились внесением в документацию предупреждения о проявлении уязвимости при отсутствии должного экранирования спецсимволов.Не, ну это не серьезно...
И вообще, какое отношение виндопроблемы имеют к этому сайту?А уязвимость нужно переименовать в BatBadButt.
> И вообще, какое отношение виндопроблемы имеют к этому сайту?Rust, node.js, Python, Ruby, Go, Erlang и Haskell уже перестали быть открытыми проектами?
Ах да, давайте тогда прекратим публиковать новости о ядре Linux, ведь оно запускается на оборудовании с проприетарными прошивками.
> уже перестали быть открытыми проектамиНе перестали. И?
Проблема из новости характерна исключительно для винды.
И это виндопроблемы мало кого интересуют.> тогда прекратим публиковать новости о ядре Linux, ведь оно запускается на оборудовании с проприетарными прошивками.
Не нужно пытаться натянуть сову на глобус.
Почему же не интересуют. После тонны линуксовых дыр очень приятно почитать, что вантузе всё ещё хуже.
> После тонны линуксовых дырЗакрытых дыр.
> что вантузе всё ещё хуже
И останется во веки веков.
Для опеннета эта новость скорее характерна.
Для хаскеля уже есть патч.В списке еще забыли жабу. Они оригинально решили проблему
Java Won’t fixAppendix B: Status of the affected programming languages
flatt.tech/research/posts/batbadbut-you-cant-securely-execute-commands-on-windows/
Проблемы индейцев шерива не волбуют
Это же не баг, а фича.
>Приложения, запускающие сценарии в формате bat и cmd на платформе Windows при помощи штатных функций запуска процессовСтолько лет - и всё одно и то же: "я разраб, мне так удобно, программа поставляется AS IS, не нравится - не используй". Это не уязвимости, это всё by design. Даже упоминания не стоит.
> The application doesn’t specify the file extension of the command,
> or the file extension is .bat or .cmdЧто бы могло сработатать, надо запускать экзешник, указав его имя без расширения. Кто и зачем мог бы такое прописать в своём коде?
>> The application doesn’t specify the file extension of the command,
>> or the file extension is .bat or .cmd
> Что бы могло сработатать, надо запускать экзешник, указав его имя без расширения.
> Кто и зачем мог бы такое прописать в своём коде?С другой стороны никто ж не запрещает делать так
rm -rf /usr /lib/nvidia-current/xorg/xorg
почему не
rm -rf /usr /lib / nvidia-current/xorg/xorg
?
Потому-что это мем про код из бамблби (насколько помню)
В Винде для запуска чего ни попадя есть ShellExecute.
Уже 12 часов назад вроде пофиксили в Rust 1.77.2.
А сколько там еще уязвимостей и бэкдоров не пофикшено и тихо ждут своего времени?
В windows? За десятилетия не разгрести, но ms-индусы не спешат, и потому приходится лепить велосипеды внутри стандартных либах ЯП.
Раст безопасный, говорили они
Раст не имеет уязвимостей, говорили они
Так в Расте и нет, а вот в windows api "CreateProcess" есть.
В конце названия уязвимости еще одной буквы "t" не хватает
>В Rust 1.77.2 в стандартную библиотеку добавлена дополнительная проверка, возвращающая ошибку при наличии в аргументе запускаемого сценария спецсимволов, которое невозможно гарантированно безопасно экранировать. Для разработчиков, самостоятельно реализующих логику экранирования предоставлен метод CommandExt::raw_arg, полностью отключающий экранирование на стороне библиотечных вызовов.То есть уязвимость как бы закрыта, но все равно остается возможность прострелить себе ногу. А те кто не экранировали ввод с raw_arg и с ним не будут. Вот такая она безопасность, в основном на словах.
Делаешь поехавшим безопасно - верещат про ограничения. Даёшь полный контроль - верещат, что не безопасно. Прямо агенты спецслужб, у которых отбирают сишку, в которой можно бекдоры внешне корректным кодом писать.
Это две совершенно разных категории попрыгавших.
Причём вторая куда опаснее.
Может и так, но слышно их одинаково громко
> Вот такая она безопасность, в основном на словах.У microsoft в windows? Не наговаривайте - birdie нам вещал, что там нет бекдоров! Это не уязвимость, а фича. Да еще за ваши деньги.
вот прикол!то есть на венде Ядро передаёт СТРОКУ в процесс а не СПИСОК_аргументов...
и при этом -- каждая программа эту страку как хочет так и разбивает?!?! по своим правилам?!
ВОТ СМЕХУТО!! АХАХАХА!! ща умру!
то есть простая операция "убери первый аргумент и то что останется передай в другой следущий процесс" -- становится НЕ РЕАЛИЗУЕМОЙ по факту ВООБЩЕ! потому что возникает вопрос -- "погоди! а по каким правилам следущий процесс будет разбивать строку? по тем же самым что и мы сами тут у себя разбили?!"
я просто валяюсь! это сделало мой день!! :-D :-D :-D
Ядро там не передаёт в процесс строку. Процесс создаётся из пространства пользователя. Ядро лишь создаёт объекты ядра (секция, основной поток).
А запуск процесса от основного потока и создание дополнительных потоков выполняется системными вызовами?
Процесс никуда не запускается - в Виндос это всего лишь изолированное от остальных адресное пространство, плюс вспомогательные структуры данных. Ядро отображает в то АП образ "экзешника", а всякие аргументы командной строки заполняет поток, вызвавший CreateProcess(). Основной поток нового процесса создаётся (если утрировать) через CreateRemoteThread(). Дополнительный поток процесса создаёт основной поток, естественно, системными вызовами.
Зачем чинить уязвимости проявляющиеся только на венде? Да ещё если это уязвимости самой венды.
Чтобы было безопасно! Сейчас в моде безопасные языки, которое позволяют безопасно работать с памятью и не только. Все должно быть безопасно по умолчанию. Пользователь должен ощущать себя в безопасности. Надеюсь мой комментарий достаточно безопасно объясняет необходимость безопасности в современном небезопасном мире. Если нет, то прошу в безопасной манере описать проблему безопасности, чтобы я мог безопасно вам ответить.
Два чая этому господину! (Не сильно горячих, чтобы безопасно. И наливать в безопасную небьющуюсь кружку неразливайку)
И подавать механическим контроллером на Ос реального времени, написанной на Ada Spark.
> При запуске bat- и cmd-сценариев на платформе Windows функция CreateProcess() неявно привлекает исполняемый файл cmd.exe, даже если приложение не указывает его при вызове.В чём проблема-то ? Всё описано в мануале. Сколько раз при вызове system в *NIX это проходили ? Никто это уязвимостью не называл.
А писать
CreateProcess( NULL,"test", ...
вместо
CreateProcess( NULL,"/my/path/test.exe", ...
такое себе ...
> В чём проблема-то ? Всё описано в мануале.Они уже сделали такое открытие.
In fact CreateProcess actively documents against using it this way:
To run a batch file, you must start the command interpreter; set lpApplicationName to cmd.exe and set lpCommandLine to the following arguments: /c plus the name of the batch file.
Господа, приведите пожалуйста пример как на С правильно обрабатывать аргументы командной строки. Как дорвусь до компьютера напишу как это делаю я — сможете раскритиковать, но напишите как правильно это делать пожалуйста.
> Господа, приведите пожалуйста пример как на С правильно обрабатывать аргументы командной
> строки. Как дорвусь до компьютера напишу как это делаю я —
> сможете раскритиковать, но напишите как правильно это делать пожалуйста.man 3 getopt
А чем getopt безопаснее? Тем более что у него только определённое применение. Разве возможно с помощью getopt обработать данные с одинаковыми названиями? Ну или если вдруг последовательность имеет значение. Более того, обрабатывает ли он в целом аргументы на такие проблемы как специальные символы?
Насколько я вижу исходный код - вроде не похоже.
https://codebrowser.dev/glibc/glibc/posix/getopt.c.html
> А чем getopt безопаснее?Поищи CVE в getopt, если тебе нужен ответ. Помню пару лет назад было что-то подобное.
> Тем более что у него только определённое применение.
типичное.
> Разве возможно с помощью getopt обработать данные с одинаковыми названиями?
колхоз. отрефакторь интерфейс, используй getsubopt(3).
> Ну или если вдруг последовательность имеет значение.
см. предыдущий ответ.
> Более того, обрабатывает ли он в целом аргументы на такие проблемы как специальные символы?
чойта у тя мисформулировано. "обрабатывает ... аргументы на ... проблемы"?
Там char*, обрабатывай чем хочешь. Вдруг тебе нужно спецсимвол передать, типа $'\n', или обработать аргумент на соответстие шаблону, getopt(3) и ко это не волнует, он делает для чего предназначен.> Насколько я вижу исходный код - вроде не похоже.
не вы%бивайся.
Ну вот так: echo hello & \e\c\h\o wo\rld \n
я получу что-то такое:
[2] 15915
world n
[1] Done echo hello
hello
А вот так: echo hello \& \e\c\h\o wo\rld \n
получается такое:
hello & echo world n
[2]+ Done echo hello
То есть в консоле символ & почему-то не экранируется а \ экранируется как \\, но самим echo не выводится. Я в целом не С программист, но иногда использую дома и не понимаю почему символ & не экранируется? В целом в Linux та же может быть проблема при вызове system. И вот getopt мне кажется в этой проблеме никак не поможет.
> Я в целом не С программисттебе надо не С, а какой-нибудь учебник по юникс-лайк системам для чайников для начала. Шеллы там, пайпы, {fore,back}ground процессы, и т.д. И потом уже С.
Как-то так:
int main(int количествоАргументов, char *аргументы[])
{
if (аргументы != NULL)
{
for (int и=1; и < количествоАргументов; и++)
{
if (аргументы[и] != NULL)
{
const char * аргумент = аргументы[и];
...
В итоге получается warning: unsafe buffer access [-Wunsafe-buffer-usage]|
> Как-то так:
> int main(int количествоАргументов, char *аргументы[])
> {
> if (аргументы != NULL)
> {
> for (int и=1; и
> < количествоАргументов; и++)
> {А где "аргументы" могут быть NULL? Вот требование стандарта:
If the value of argc is greater than zero, the array members argv[0] through argv[argc-1]
inclusive shall contain pointers to strings, which are given implementation-defined values
by the host environment prior to program startup.
Очередная победа сишников и плюсовиков над растаманами!
Ничего даже делать не пришлось.