В NPM-пакете tar-fs выявлена...Подробнее: https://www.opennet.me/opennews/art.shtml?num=63740
А это нормально, когда уязвимость в NPM, а в качестве примера код на python ?
код, подготавливающий проблемный файл, может быть на любом языке
Эт че, в NPM опять что то корявое выложили?
Они там концептуально не обучаемые походу, эти NPM-щики.
Косяки с разбором путей и симлинков во всех языках встречаются, особенно часто в либах на Cи, NPM тут не причем. Кстати, прям в этой же новости - в 7zip тоже npm виноват?
> уязвимость в NPMнадо было NPM на безопасном языке писать.
Нужен язык для безопасной работы с символическими ссылками.
как насчет RUST?
там у них есть unsafe!
есть что возразить?
Так а кто там проверяет символические ссылки, чекер боровов проверяет?
Надо запрос разработчикам запилить. Что бы добавили в язык безопасность работы с символическими ссылками.
в расте ссылки проверятся на этапе компиляции с zero-cost ценой.
Ну дык... Плюсовый llvm же
chroot
Почему программисты тупо не умеют работать с ../../ ? Что сложного, а?
Ты тоже не умеешь
Важное уточнение - программисты яваскрипт.
Не знал, что 7-zip написан на яваскрипт.
Интернет система , ой у нас уязвимость мы вышли за пределы интернета. Собираем на мак с помощью linux /.../.../.../ , ой а чё это мы собираем linux библиотеки на мак , опять вышли за пределы эипла. Вот на что похожи эти новости
Есть хороший лайфхак по генерированию "новостей" - смотришь в NPM репах с чем там они на этой неделе обосрались, и у тебя куча контента.
Если не прокатило - вспоминаем, что в NPM теперь можно подключать сторонние репы, и далее переходим к пункту 1.
Господа, так может следует сначала просто определиться, разрешено ли вообще архиватору распаковывать файлы куда угодно, кроме того каталога в котором лежит файл (естественно при наличии соотвествующих прав доступа в файловой системе). А именно это я прочитал в новости - "в любые части ФС, не ограниченные каталогом, в который осуществляется распаковка"Например достопочтенный гуевый винрар (как и 7zip), позволяют пользователю вручную указать директорию для распаковки (пока не учитываем "специально подготовленные архивы" с кривыми путями) - вот это хорошо или плохо?
Может вопрос-то просто в корявой обработке путей архиваторами?
Я могу положить внутрь архива символическую ссылку с путём "nop" и содержимым ".", а следом за ней ещё одну символическую ссылку "yousuckatparsingsymlinks" с содержимым "nop/nop/nop/..". Всё, теперь следующий файл кладём с путём "yousuckatparsingsymlinks/outoffolder", и при распаковке он окажется снаружи папки, куда ты распаковывал архив. Проблема элементарная - забыли в режиме ограничения пути распаковки (по дефолту tar позволяет любые пути в нём записать, что удобно для тех же обновлений системы) разыменовывать содержимое симлинков и проверять уже реальный путь, куда они будут указывать. Тут даже парсер переписывать не надо - только readlink делать при встрече любой симлинки.
Я так прикинул, в симлинках же можно любой путь указать, в том числе абсолютный "/tmp" или "/etc". Если не проверяется реальный путь с подставлением содержимого симлинки, то наверное не проверяется и то, что в симлинке лежит абсолютное перенаправление, которым можно сразу попасть в нужную часть FS.
chroot
Вот почему я предпочитаю ACE.
Что такое ACE?
тетя Ася плохого не посоветует
>>Вот почему я предпочитаю ACE.у себя дома можно предпочитать все что хочешь - хоть хомячков, хоть няшных котигов.
но и ногда из лесу приходится брать диких животных.
Настоящие гигачады используют ARJ