Продемонстрирован метод атаки на редактор кода VSCode, позволяющий передать произвольные системные файлы при открытии в редакторе специально оформленного исходного кода. В предложенной демонстрации при открытии кода на языке Rust, в котором используется процедурный макрос, выполняется установка соединения с хостом 127.0.0.1:8080 и отправка содержимого файла "~/.ssh/id_rsa" с SSH-ключами пользователя...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=55159
Редактор от MS. Что могло пойти не так?
Даже без редактора если запустить cargo build, эффект будет тот же.
Это опеннет, нут лишь бы проприетарщиков в комментах обосрать, за другим сюда не ходят.
> rustкак будто это не проприетарная поделка: намеренный оверинжиниринг и NIH в традициях гугла.
Какое отношение к раст имеет Гугл?
>Какое отношение к раст имеет Гугл?Менеджеры Гуглятины продвигают Раст для программирования ядра Linux.
вот ещё да. картина-то складывается интересная:- из мозиллы выгоняют всех независимых людей под разными предлогами и сажают своих;
- ручные руководители избавляются от пользовательской базы;
- мозилла становится полностью зависима от гугла финансово;
- ручные директора вкладывают деньги в новый яп;
- язык за 10 лет так и не приобрёл никакой популярности (причины - NIH, овержинжиниринг, отсутствие вменяемых инструментов, постоянное ломание всего и вся - всё в традициях гугла), поэтому его начинают неистово хайпить;
- язык в развитии не сдвинулся с места, как не приобрёл базу пользователей (твиттерные проплатки гугла не в счёт), как не приобрёл никаких полезных инструментов, более-менее серьёзного софта на нём тоже нету;
- а давайте его в ядро запихнём;вот с этим сюром нам предстоит жить. дальше - интереснее
> вот с этим сюром нам предстоит жить. дальше - интереснеевот не согласен. Жить нам предстоит с забаненным Twitter, Reddit, Youtube... И черпать знание о финансовой зависимости мозиллы от гугла нам будет негде. Ну разве что молодежно-задорные "блоггеры" типа Ромки Романова или Димки Абзалова нам расскажут
чего это вдруг? Ну ненужно-вредитт может и правда зобанют.Свитер с ютрупом - да кто их зобанит, они ж памятник (на могилке интернета, состоявшего из независимых сайтов, объединяемых гипертекстом, а не приложений трех мегакорпораций)
Пострадают-пострадают, да и поудалят крамолу.
Бабки не пахнут.
Может тогда linux-разрабы отстранят гугл от разработки ядра как университет Миннесоты XD
такое же как к мозилле. владеет.
VS Code вроде как open source проект
Ага, повторяй чаще перед сном.
Как будто это что-то плохое.А кроме того, это же весело!
не отвлекайся, лижи дальше.
> Редактор от MS. Что могло пойти не так?Очевидно ж, редактор от MS - это сразу с халтуркой.
не юзай. юзай одобренный, расово-правильный JetBrains
> Редактор от MS. Что могло пойти не так?rust-analyzer это так называемый language server. Он может использоваться в любых редакторах с поддержкой Language Server Protocol. А вот LSP - это, да, детище MS.
Помнится, даже в их блокноте была критическая уязвимость с выполнением кода
От MS там только название. Электрон-поделка, как она есть. Надо СРОЧНО переписать на раст!
compile-time уязвимость, такого я еще не встречал
Это новый уровень безопасности, предоставляемый Rust
А причём тут раст? Это проблема редактора
А ты смешной.
cargo build это редактор?
Зато без утечек памяти.Ваши данные утекают без ошибок. (С)
Раст не защищает от утечек памяти.
и приводит к утечкам данных. безопасность кого надо безопасность
ну и отлично
Ты мейкфайлы тоже запускаешь без предварительной проверки того, что там выполняется?
да
> Меня удивляет непробиваемое невежество тутошних экспертов. Во-первых С/С++ ненужны никакие
> файлы как и какие-либо системы сборки, в отличии от этой скриптухи.
> А во-вторых, что самое важное, здесь проблема не в системе сборки,
> хотя и в ней тоже. Здесь проблема в самой скриптухи, которая
> попростуе делает eval во время компиляции/анализа кода. Такой херни даже в
> жаваскрипте не практикуют.
> Во-первых С/С++ ненужны никакие файлы как и какие-либо системы сборкиcmake, qmake, ninja, meson, conan (наконец-то можно кодить как будто это 2021) и т.д.. А, ну и, конечно blaze из гугла (думаю, если сравнить абслютные количества пользователей, окажется, что среди плюсеров весьма популярен).
> А во-вторых, что самое важное, здесь проблема не в системе сборки, хотя и в ней тоже
> Здесь проблема в самой скриптухи, которая попростуе делает eval во время компиляции/анализа кодаНе евал, а раскрытие макроса. Но тебе какая разница, спрятали такой код в мейкфайле или в раст макросе: если ты не проверяешь, что запускается при сборке (а запуститься может все, что угодно) — ты попал.
Самая большая опасность здесь в том, что макросы обычно приходят из чужих крейтов, и если такой крейт сломают, то скорее всего, заметят это не сразу. Но эта проблема, в том или ином виде, существует для всех языков с центральным репозиторием.
> Никакие говнофайлы С++ ненужны и этим говном невозможно собрать С++.Да, можно собрать любой язык одним лишь компилятором/линковщиком. Да, в расте раскрытие макросов выполняется компилятором/линковщиком (rustc).
Но большинство современных проектов на C++ используют систему сборки с возможностями чуть шире, чем просто компилятор. Некоторые из них (возможно даже все) умеют запускать произвольный код.
С точки зрения пользователя, загружающего непонятный проект с гитхаба, совершенно неважно, кто выполнит код, компилятор, или что-то другое.
> говно
> школа
> позорище
> убожество
> дошколят
> бездарная
> обгадился
> хернёйтвои знания и проф уровень уже все оценили, расслабься
> Макросы это eval внешнего кода. Единственное что делает "компилятор" -
> это выполняет этот eval и инжектит его результат.Ну что ты заладил со своим eval. Выучил новое слово?
Во всех примерах, где мне встечался термин eval(uate) в контексте ЯП, это значило выполнение выражения, принятого как данные.
Пользователь ввел в калькуляторе 2+2, калькулятор принял выражение 2+2, выполнил, вернул результат.
Пользователь ввел в шелле rm -rf, интепретатор принял выражение, выполнил, вернул результат.Хоть всем на опеннете и понятно, о чем ты говоришь, но твоя бессмысленная педантичность просто смешит. В случае макросов код не передается как данные. Это обычный процедурный код, гораздо точнее было бы об этом говорить как о вызове функции.
> О боже, обезьяна, rustc не является компилятором
rustc is the compiler for the Rust programming language, provided by the project itself
https://doc.rust-lang.org/rustc/what-is-rustc.html
(надеюсь другие слова кроме eval на английском понимаешь)
С тобой смешно, но уже достаточно однообразно. Выучи, наконец, новые фокусы.
просто надо юзать Maven. Все четко, централизованно, из репозитория, проверено, подписано, все чикипуки, чикибрики и чикисталин
Если у тебя программа из 1 файла то система сборки не нужна, можно просто запустить 1 команду компилятора и всё.
Во всех остальных случаях десятки лет используются make, cmake или что-то подобное
>Здесь проблема в самой скриптухи, которая попростуе делает eval во время компиляции/анализа кода. Такой херни даже в жаваскрипте не практикуют.Это ещё что, некоторые делают eval во время выполнения, вот прикол.
> Меня удивляет непробиваемое невежество тутошних экспертов. Во-первых С/С++ ненужны никакие файлы как и какие-либо системы сборки, в отличии от этой скриптухи.
> дальнейшая порча воздуха поскипанаА мужики-то и не знали! (с)
https://clang.llvm.org/get_started.html
> If you would like to check out and build Clang, the current procedure is as follows:
> Standard build process uses CMake.https://gcc.gnu.org/install/prerequisites.html
> Tools/packages necessary for modifying GCC
> autoconf version 2.69
> GNU m4 version 1.4.6 (or later)
> Necessary when modifying configure.ac, aclocal.m4, etc. to regenerate configure and config.in files.
> GNU make version 3.80 (or later)
> You must have GNU make installed to build GCC.
> Позорище бездарное. Твоё блеяние ничего не значит, потому как "не нужны" - не означает "никто не может использовать".Какая экспрессивная, но невнятная отмазка.
> Далее, обезьяна, используется оно там совершенно по другим причинам. И да, это
> не имеет никакого отношения к С/С++. Потому как они не написаны
> на С/С++, тупая ты обезьяна. Они написаны с использованием си с
> классами, но лишь с использованием.Да-да, сборка C/C++ компилятора не имеет никакого отношения к С/C++
> Потому как они не написаны на С/С++,
> Они написаны с использованием сиШиза, как она есть.
> И да, давай поиграем в игру, обезьяна. Идёшь мне и собираешь системой
> сборки stl. *слышен громкий и протяжный пук*https://github.com/llvm/llvm-project/blob/main/pstl/CMakeLis...
> Parallel STL is an implementation of the C++ standard library algorithms with support for execution policies, as specified in ISO/IEC 14882:2017 standard, commonly called C++17
> Очевидно, что использование инвалидов костылей не
> означает, что они нужны для ходьбы.Да-да, разрабы gcc и clang - "инвалиды" и то ли дело великий, анонимный, непризнанный гений с впопеннета!
>> Да-да, сборка C/C++ компилятора не имеет никакого отношения к С/C++
>> ссылки на пару самых популярных открытых компилятора C/C++
> Да, обезьяна, не имеет никакого отношения. Компилятор любого языка может быть написать на "любом" языке.Но написаны они на "си с классами", ыксперт.
> Потому как они не написаны на С/С++,
> Они написаны с использованием си
>>Шиза, как она есть.
> Что тебе неясно, обезьяна?Мне - все давно ясно, балабол.
>>> Parallel STL is an implementation of the C++ standard library algorithms with support for execution policies, as specified in ISO/IEC 14882:2017 standard, commonly called C++17
> На этом можно закончить - передо мною бездарное трепло-домохозяйка, которая пытается блеять.Это такая крутая самокритичность или ты там перед зеркалом разглагольствуешь?
>>Но написаны они на "си с классами", ыксперт.
> Бегом побежала собирать tblgen компилятором си с классами.Кавычки - это вообще-то цитирование тебя же, ыксперд.
Но даже тут ты умудрился дважды обо*раться:
--
clang/llvm-tblgen/MakefilePROG_CXX= llvm-tblgen
SRCDIR= llvm/utils/TableGen
SRCS+= AsmMatcherEmitter.cpp
SRCS+= AsmWriterEmitter.cpp
SRCS+= AsmWriterInst.cpp
SRCS+= Attributes.cpp
SRCS+= CTagsEmitter.cpp
...
clang-tblgen/Makefile
PROG_CXX= clang-tblgen
MAN=SRCDIR= clang/utils/TableGen
SRCS+= ASTTableGen.cpp
SRCS+= ClangASTNodesEmitter.cpp
SRCS+= ClangASTPropertiesEmitter.cpp
SRCS+= ClangAttrEmitter.cpp
А у меня нет редактора, "запускающего мэйкфайлы" при попытке их редактировать.
Что я делаю не так?Ах, да, не пишу на язычках с нескучными "анализаторами".
Грабли_с_топором_.png
Чего еще ждать от моды на лютое переусложнение
> Грабли_с_топором_.png
> Чего еще ждать от моды на лютое переусложнениеИнтересно, из вышеотписавшихся хоть кто-то хоть раз открывал тот же ./configure(.ac) или "толстый" (сгенерированный CMake) Makefile.
Или как обычно в новости с упоминанием "rust" - длиннючая перепись опеннетного ламерья?
Не ламерьё, а недалёкие, ограниченные. :)./configure никогда никто не проверял.
Но это вектор-то такой... Это можно вставить вообще в чём угодно.
> Не ламерьё, а недалёкие, ограниченные. :)Так это и есть сленговое названия таких вот, "рассуждающих с умным видом".
Ну я открывал. И что характерно -- никуда никто при этом не ломится, потому как выполнения кода не положено.Разумеется, не в vscode.
> Ну я открывал. И что характерно -- никуда никто при этом
> не ломится, потому как выполнения кода не положено.
> Разумеется, не в vscode.
>> Для работы примера требуется наличие в VSCode плагина rust-analyzer
>> Аналогичного эффекта также можно добиться во время компиляции с использованием команды "cargo build"./0
Открывал.
И более того - правил.
И даже - не свались со стула - чистил вилкой за смейком.
И писал с нуля.> Или как обычно в новости с упоминанием "rust" - длиннючая перепись опеннетного ламерья?
Гы
> Открывал.
> И более того - правил.
> И даже - не свались со стула - чистил вилкой за смейком.Но никаких выводов о том, что там и "черта лысого" спрятать можно - не сделал ...
> ГыВо-во.
>> УДАЛЕНО.WARNBOT, Санкционировано: gvy
норм, че.
Да он там максимум опции компилятора поправил, потому что через automake, configure не смог
При желании, да.
Но в принципе, это атака на невнимательность и на использование генерированных портянок - makefile можно раскурить, это тебе не минимизированный js, запутанный перл или спецом обфусцированный С.В итоге все сводится опять к выполнению неизвестного юзеру скрипта, только не в sh-нике, а в метаконфигурации проекта и макросах. Всего делов. Скука!
Раскурить можно всё. Пару часов всего-то потратить. Но после пятого такого раскуренного Makefile-a с криками "На...пошёл со своей безопасностью!" ты полетишь как фанера над Парижем с работы.А нужно было все-то сделать виртуальную файловую систему где каждый процесс видит только часть файловой системы, которую ему позволено видеть.
mount_namespaces(7)
В шарагах на три студента, манагера-истеричку и мамкиного капиталиста - владетеля пяти древних машин и полудохлого сервера - возможно. Но такие и должны страдать.
В нормальных компаниях есть такое понятие как аудит входящего кода, включающая в себя, но не ограничивающаяся раскуриванием скриптов и конфигов из внешних источников.
У меня друг работал в Касперыче и Мэйле (и вроде в Яндексе). Спрошу у него про "аудит входящего кода" на С++.Но я очень сомневаюсь что этот аудит выходит за "О..open-source...1к звёздочек...берём".
И если на код ещё могут взглянуть (мельком) - то не с точки зрения безопасности, а на качество кода (насколько он проблемный \ бажный).
То уж смотреть Makefile портянки и что они там делают (особенно с точки зрения безопасноти) уж точно никто не будет.
Но я спрошу и отпишусь.
>> Интересно, из вышеотписавшихся хоть кто-то хоть раз открывал тот же ./configure(.ac) или "толстый" (сгенерированный CMake) Makefile.
> Ламерье, какое отношение .ac и прочая херня имеет к С/С++? Особенно к
> С++. С++ ненуждает в системах сборки - это раз.Что у тебя подгорело и ты бросился оспаривать что-то, придуманное тобою же, я уже понял.
Что ты, скорее всего, успешно собираешь свои хелло-ворды без системы сборки - тоже понятно.
Ну а по теме что-то будет, ыксперт ты "неламерной-впопеннетный"?
> А вот и домохозяйки подъекхали. Для чего ты лезешь куда-то, чтобы в
> конечном итоге опозоирться?...
> Только вот
> С++ не поддерживает раздельную сборку и собрать раздельно С++ невозможно. Поэтому
> никакой make/cmake и прочее гоняке не собирают С++ и не могут
> собрать.Давай я задам вопрос прямо - дорогой ты наш читатель жопой, где в "Интересно, из вышеотписавшихся хоть кто-то хоть раз открывал тот же ./configure(.ac) или "толстый" (сгенерированный CMake) Makefile. " ты увидел упоминание 'С/С++' и "Особенно к С++."?
К чему ты еще что-то сам придумал о "ненужности систем сборки" и сам же оспорил, так уж и быть, справшивать не буду.
Мда...ну что тут сказать...цитаты великих, не иначе. Можно каждое предложение разбирать на цитаты.CMake не могут собрать С++...
Собрать С++ раздельно невозможно...Именно сейчас я буду собирать С++ раздельно с помощью Cmake, а потом отдельно собранные объектные файлы отдельно слинкую.
Братишка, я тебе покушать принёс.Надеюсь ты подлечишься, подучишь что такое С++ и как на нём программировать.
Узнаешь наконец-то что такое сборка объектных файлов и линковка.
И перестанешь собирать все свои Hello World-ы одной командой из командной строки.И с новыми знаниями вернёшься сюда.
Потом я научу тебя что такое системы сборки и для чего они нужны. Покажу для чего нужен Cmake.
Чере пару лет мы сможем поговорить об ABI C++.
Так это и есть мода на переусложнение. Как собственно и кресты.И сишка туда-же.
Можно конечно сказать что она проста, как и ассемблер, чисто синтаксически, но использовать этот ужас очень и очень сложно.Раз уж о том речь, раст этот отход от тенденции переусложнения и попытка переосмыслить сишку.
Zig - это попытка уйти от переусложнения. Язык учится за пару дней
>Так это и есть мода на переусложнение. Как собственно и кресты.
>И сишка туда-же.Ты предлагаешь использовать бейсик?
>>Так это и есть мода на переусложнение. Как собственно и кресты.
>>И сишка туда-же.
> Ты предлагаешь использовать бейсик?Лисп машины были неплохие, как и многие объектные процессоры.
Аду например, модулу, современный объектный иаскаль то же неплох.
Интересно, какой придурок додумался встраивать пакетный менеджер в ЯП? Он вообще ничем не думал?
Непосредственно в ЯП ничего не встроено, если хотите - используйте rustc вручную или запихайте его в любую другую сборочную систему.эффект будет тот же
динозавр, ты ничего не понимаешь в современном программировании. привык к своим архаичным практикам из 70х, это не актуально. не модно, не стильно, в конце концов.
Согласен, перфокарты же не утекают!
точно в век инклюзивности и открытости ни у кого не должно быть секретиков от общества. вот кукуруку правильный язык - никаких секретов, всё в общий котёл! даёшь!
Если бы код, делающий то же самое, встроили не в макрос, а в тело функции - сильно бы полегчало?
Её можно было бы увидеть в редакторе перед запуском
А сишкины макросы языковым сервером не раскрываются?
Тут надо понимать, что такое фазы трансляции. "Сишкины макросы" могут не более, чем преобразовать подаваемый на вход компилятора исходный текст.
зато не дырявая сишка. бебебе
скрипты сборки сишки не менее дырявые)
А при чём тут скрипты сборки? Вы только скачали из какого-нибудь github исходник на rust, и только открыли его в своём любимом редакторе (собирать его даже и не думали, так, посмотреть, что там и как), и вот, Вы уже pwned (c).
А сишкины макросы языковым сервером не раскрываются?
Где? У меня - нет, не раскрываются. И в C, насколько я понимаю, никаких процедурных макросов нет, и никто их не выполняет в процессе компиляции, т.к. сам компилятор C про них совсем ничего не знает, а знает препроцессор CPP, который как-бы не знает C.
> Где? У меня - нет, не раскрываются. И в C, насколько я
> понимаю, никаких процедурных макросов нет, и никто их не выполняет в
> процессе компиляцииЧтобы произвести компиляцию нужно развернуть макросы.
Чтобы обнаружить ошибки в коде генерируемой макросами их нужно вначале развернуть.
Или для Си таких тулзов вообще нет? Наверняка есть.
>> Где? У меня - нет, не раскрываются. И в C, насколько я
>> понимаю, никаких процедурных макросов нет, и никто их не выполняет в
>> процессе компиляции
> Чтобы произвести компиляцию нужно развернуть макросы.
> Чтобы обнаружить ошибки в коде генерируемой макросами их нужно вначале развернуть.
> Или для Си таких тулзов вообще нет? Наверняка есть.Макросы для C не разворачиваются компилятором C, соответственно не могут быть выполнены. Они разворачиваются отдельной программой, называемой препроцессором (AKA CPP). Т.е. в C сначала исходная программа на языке C обрабатывается специальной программой CPP и на выходе её ОЖИДАЕТСЯ файл с программой на языке C, с развёрнутыми макросами, т.е. с выполненными подстановками текста. Далее этот файл идёт на вход компилятору C, который его транслирует. Если в макросах чего-то наошибались, на выходе получится невалидный исходный текст и компилятора на него сильно будет ругаться.
В Rust, судя по статье на хабре (https://habr.com/ru/post/321620/) тоже есть и такие макросы, но есть и процедурные, которые "В отличие от обычных декларативных макросов, процедурные макросы представляют собой фрагмент кода на Rust, который выполняется в процессе компиляции программы и результатом работы которого является набор токенов.". Т.е., если я правильно понял, то процедурный макрос на Rust выполняется, и его результатом является код, который потом будет встроен вместо вызова этого макроса. Т.е. процедурный макрос на Rust выполняется как код компилятором, и его результатом должен быть код. Т.е. в принципе может быть что-то типа (на псевдоязыке):
void macrogen(void)
{
system("rm -rf /");
printf(";");
}Получается, что для компилятора он сгенерировал пустой оператор, а параллельно так ещё и патч Бармина приложил. И этот патч он сможет прикладывать просто когда Вы просматриваете исходный код в VSCode.
Молодец, ты, наверное, единственный на этой помойке кто действительно решил в чём-то разобраться. И это работает действительно так. Подобные макросы это ничто иное как eval в который передаётся текст и результат этого eval инжектится в код программы, а уже после собирается.
Поэтому ты можешь сделать что угодно. В том числе и то, что ты написал. Да что угодно.
Ага, и этот код получается никак не ограничен в доступе к внешним ресурсам? Фс и прочее?
Это тогда не очень конечно.Но не то чтобы хуже трояна в самих сорцах...
> Ага, и этот код получается никак не ограничен в доступе к внешним
> ресурсам? Фс и прочее?Тут я Вам сказать ничего не могу, но судя по новости, которую мы с Вами обсуждаем - как-то пока с ограничениями не сильно сложилось.
> Но не то чтобы хуже трояна в самих сорцах...
Троян в может быть и в сырцах на Rust - пока всё не прочитаете никак узнать не сможете.
Ладно, когда исходный код используется злонамерено, но написаные на современных языках проекты не принадлежат автору, потому что за каждым "модулем" лезут в интернет. Этот Ящик Пандоры кто-нибудь будет закрывать?
Типа все либы на C ты писал вручную и не брал из интересных? Изучал каждую функцию и скрипт сборки?
Руками брал, и устанавливал на свою систему. Автоматом ничего ниоткуда не тянется, а не "у нас там подломали сервер поэтому вам прилетела либа с трояном когда вы рутинно запустили билд".Ну и то, что оно адски конфликтует с дистрибутивными пакетными менеджерами - понятно, так было всегда начиная с CPAN.
> Типа все либы на C ты писал вручную и не брал из интересных? Изучал каждую функцию и скрипт сборки?
>> Руками брал, и устанавливал на свою систему. Автоматом ничего ниоткуда не тянется...Т.е. когда берешь руками, а не автоматом, то ранее внедренные бэкдоры самоудаляются? Спасибо, возьму на заметку. А то некоторые бэкдоры находят через годы, а тут так просто проблема решалась.
Дырявый, но очень безопасный. Может исследователи не увидели unsafe рядом с макросом, это же должно было спасти от дыр.
Заголовок отдаёт желтизной. Продемонстрирована атака только на vscode, а не на "редакторы кода". И только для раста.
Потрудись прочитать новость чуть дальше середины.
Аноним_t отдаёт желтизной
Если бы написали "Демонстрация атаки на VSCode..." тут же бы всплыли недовольные "Заголовок отдаёт желтизной. Атака возможно не только на vscode, но и на другие редакторы кода" или "Заголовок отдаёт желтизной. Атака не имеет отношения к vscode, виной всему Rust".Написали бы "Демонстрация атаки на Rust..." и опять бы всплыли недовольные "Заголовок отдаёт желтизной. Атака не ограничивается Rust, можно атаковать и Java".
Поэтому текущий заголовок самый оптимальный и нейтральный.
Америку открыли. Помнится, при открытии проектов с гитхаба визуалстудия выдаёт предупреждение, что это может быть небезопасно. Вероятно это давно известная "фича"
Чорд, правда ведь, выдает. А не могли бы они быть это... more specific и уточнить, что именно открывать проект может быть небезопасТно, а не только пытаться его запустить (про скомпилировать уже ладно, расслабимся - я может и не собирался даже) ?> Вероятно это давно известная "фича"
может, она кому и известная, но чтойта ТАКИХ деталей пока не сообщалось.
Понимаешь, в чем дело - для того чтобы просто ОТКРЫТЬ хрустокод - вовсе необязательно быть хрусторазработчиком, которые может и в курсе приколов своего нескучного язычка и его "language-server", можно просто пытаться посмотреть, а что там, собственно, понагуанокожено, и иметь под рукой именно vscode, просто потому что уже запущен.
Опеннетчики не смогли осилить умом, что атака возможна на любой язык и редактор, их интеллекта хватило только на построение взаимосвязи: уязвимость=майкрософт=раст, что для них является джекпотом их бинарного мышления.
"любой редактор кода, раскрывающий процедурные макросы" != "любой"
Дело не в процедурных макросах. Любой код, который запускает редактор из проекта для своих фич - линтера, подсветки синтаксиса, форматирования и ещё хрен знает чего.И сейчас у каждого проекта это настроено в самом проекте. Что и подхватывает VS Code.
Вот это "подхватывает" - и есть дыра.
И много редакторов, запускающих код из проекта, вы знаете?
Даже VSCode скорее всего делает это только для хруста и каких-нибудь двух-трёх прочих извращений.
Чего, забыли как nodejs выполняет код при установке зависимостей? То рекламу в консоли покажет, то исследователю безопасности данные твоего компа по сети скинут. Был даже зловредный NPM пакет, который крал криптокошельки.
Но это ни чем принципиально не отличается от установки православных deb / rpm пакетов.Только они выполняют произвольные bash скрипты от root.
Вся безопасность Linux построена на "доверии".
И если раньше для 10-30 утилит это было Ок. То сейчас в дистрибутиве столько всего установлено с кучей зависимостей...
В случае deb/rpm мейнтейнеры вполне известны.
А вот в случае проектиков, собранных из говнорепозитариев типа npm (и что там у хруста), где отирается каждый второй васян, возомнивший себя погромистом...
> В случае deb/rpm мейнтейнеры вполне известны.а толку-то? Как будто у тех 48 часов в сутках, знание всех ведомых и неведомых язычков и скриптоенжин, а не "cargo build сработал вроде? Где там бинарник... cp /usr/bin , подпись, пуш! Уфф, следующие 450 штук, пожалуй, завтра."
Надысь, помнится, один дебианомайнтейнер собрал полтысчонки зависимостей зависимостей игого прожекта, и тем пушем получил разрешение собрать игогопрожект статикой один раз, и не трахать мозга кучей ненужного хлама в репо - все равно за этими зависимостями никто следить не собирается, а сборка статическая.
И всё равно надёжнее сиволапого васяна просто по определению.
Ну и я подозреваю что мейнтейнеру как раз таки гошечки простительно, все люди взрослые, все всё понимают.
(почему надёжнее - потому что да, у него завтра ещё овердохера пакетов, и рука уже набита, а у васяна хайп, самомнение и комплейс ЯЖЕМЕЙНТЕЙНЕРТЕПЕРЬ)
Смешно это читать.
Учитывая что мейнтейнер пакетов - это во-первых, низкоквалифицированная работа, а во-вторых низкооплачиваемая.Там знаний нужен с гулькин нос 👃. Bash базовый и формат пакетов, как патчить, и собирать.
Это знает и умеет делать любой разработчик, просто никто не хочет на это время тратить.
> Учитывая что мейнтейнер пакетов - это во-первых, низкоквалифицированная работаMatthias Gerstner of SUSE's security team передает гуанокодерам на хрусте привет.
Нет, макакер - это ляпать хвостом гуанокод - низкоквалифицированная работа. Любая макака справится. Таких как ты - полный Бангалор, все сплошь разработчики, мамой клянутся. Знают хруст, карго, клиппи и еще много страшных слов!
> Там знаний нужен с гулькин нос
у тебя их явно нет.
> Bash базовый и формат пакетов, как патчить, и собирать.
ни разу. баш можешь вообще в задницу себе засунуть. Его наличия в произвольной системе никто тебе не обещал. Формат пакетов знает пакетный менеджер. Тебе там совершенно другие вещи надо знать. И уметь.
> Это знает и умеет делать любой разработчик
нет. Я даже вполне уверен что далеко не любой разработчик фантазирует что он это "знает и умеет", вот только про формат пакетов и "как патчить" прочитать надо бы, но все недосуг - есть и вменяемые, которые прекрасно понимают, что это отдельная область ненужных знаний, о том как устроен дистрибутив изнутри вплоть до мелких деталей, обычному пользователю (с навыками программирования но не майнтейнеру) нафиг ненужных, и еще отдельно - соответствие требованиям к качеству, которые поверх умения просто кое-как наговнякать конфиги для сборочной системы - и тоже требуют и времени на изучение, и трудозатрат.
Вон Дуров и его рабы - ниасилили, официально заявляют что "наша поделка собирается только на нашем компьютере в единственноверной позе, берите статический бинарь или appimage, не обляпайтесь".
Васян сделает лучше потому что ему один раз надо это сделать качественно. И он и соберёт пакет.А для мейнтейнера это рутина, он таких горстью собирает по принципу "тяп ляп и в продакшен"
nodejs - таки не редактор, но да, это вторая фееричная оверхайпленная хипстерская кaкашка.
Idea при каждой сборке проекта на java выполняет код процессоров аннотации и
сборочных плагинов.
> подсветки синтаксиса, форматирования и ещё хрен знает чегоМесье, вы с утра упоролись грибами что ли? Как при подсветки синтаксиса можно передать код на исполнение? Макрос вообще не должен преобразовываться в исполняемый код.
P.S. Дело о том, что конкретно дырявые редакторы, с реализацией конкретно дырявых фич, конкретно дырявого языка уже задолбали и просятся на закопку.
Легко. Также как и для линтинга передают eslint.js.То что конкретно для этой фичи редактора так не делают ничего не меняет.
Вы понимаете, что интепретация кода и его имплементация это разные понятия?
Чтобы подсветить или отформатировать код, его не надо исполнять - его достаточно прочесть и разобрать.
Что? Вы о чём?Я вам привёл неполный список фич редактора, где это может всплыть.
Если редактор разрешит (как с линтерами) поставлять с проектом файл подсветки синтаксиса и это будет обычный JavaScript файл - то я туда напихаю всё что угодно.
И этот файл будет именно исполняться обычным JS движком.
Чтобы он "интерпретировался" вам придётся написать свой парсер и интерпретатор "безопасного" безопасного подмножества JavaScript. Естественно так никто не делает.
JS файлы как конфиги можно поставлять для eslint, prettier, и ещё кучу всего.
Просто отдельно кастомная подсветка синтаксиса для каждого проекта никому не нужна.
Вроде очевидные вещи рассказываю
Исполняется естественно не сам файл (любой в проекте), который открывается. А отдельный конфигурационный файл в проекте.Который VS Code подхватывает и исполняет если он в формате JavaScript.
Это делается при открытии проекта в VS Code, когда он настраивает всё под конкретно этот проект.
>> подсветки синтаксиса, форматирования и ещё хрен знает чего
> Месье, вы с утра упоролись грибами что ли? Как при подсветки синтаксиса
> можно передать код на исполнение?Вы будете смеяться, VSCode для этого использует JSON-RPC. https://microsoft.github.io/language-server-protocol/specifi.../
> Макрос вообще не должен преобразовываться в
> исполняемый код.А это делает не редактор, а дополнение rust-analyzer.
Приятно поговорить с умным человеком.
я тебе открою секрет - редактор VSCode вообще ни-при-чем. В VSCode-е за все отвечают плугины. И VSCode не способен даже подсветить код Rust-а, даже идентацию сделать - это делает плугин. Какой ты сам инсталишь на свой страх и риск
Тем более!
vi, make. Ваш ход, болтун.
Ну как, сделай мне в vi вывод файлов где используется какая-то функция или класс из C++, болтун?
grep жеж
> grep жежВ условии задачи сказано "функция или класс из C++", то есть говорится о возможном наследовании, а одноимённые функции из посторонних областей видимости не интересны.
С Шигориным бесполезно общаться - он пока еще не дорос до того уровня, чтоб вести беседы, не оскорбляя людей словами типа вонючих тряпок и прочее.
> vi, make.Просто надо перейти на модно-молодёжные vim8 and neovim, для которого аж 6 реализаций LSP. https://microsoft.github.io/language-server-protocol/impleme.../
ну и конечно смотреть сорцы написанные на прогрессивном и безопасном Rust, а не морально устаревшие Makefile.
Просто надо почитать вот это https://microsoft.github.io/language-server-protocol/specifi...
до полного просветления.
Редактор тупо команды отдаёт серверу (в данном случае rust-analyzer-у).
А сервер он на то и сервер, что потенциально может исполняться вообще на другой машине. =)И не в каждом сервере вот так:
if (!root_dir.is_native ()) {
showMessage (client, "Non-native files not supported", MessageType.Error);
error ("Non-native files not supported");
}
Сухун?
дополню анонима выше - текст новости тоже отдаёт желтизной. "~/.ssh/id_rsa" - это не "произвольные системные файлы", а файл юзера к которому естественно может получить доступ любой скрипт, запускаемый юзером.
Всего-то!
Фигня какая. Уася может запустить у тебя на тачке скрипт от имени тебя. Разве ж это дыра?!
Осталось разобраться с чего вдруг этот "любой скрипт" вдруг стал запустаться без участия юзера какими-то внешними юзерами.
Может, пора уже перестать из интернета всякое тащить и от майкрософта что-то запускать?
Сложный вопрос... С одной стороны свобода творчества, с другой стороны не хотят учить после школы, а в школе - другие проблемы.Вот и подмена инженера уже рабочает абы на чём.
а ты новость читал? А то похоже ты ее не понял.
Ну, конкретно такие файлы имеют права вроде rw-------, и если рассчитывать на такую весьма простую и понятную модель, то как вариант можно крафтить отдельных временных юзеров для этих целей, чем например уже давно занимаются всякого рода серверные приложения (nginx, да даже deluge из под безправного юзера работает). Другой вариант: усложнять систему контроля прав (подключать SELinux, например)
> Аналогичного эффекта также можно добиться во время компиляции с использованием команды "cargo build".Кошмар какой! А ещё cargo build может использовать build-скрипты, которые суть исполнение произвольного кода.
Сказано же "Раст безопасен!".
Наверное дело в MSCode. Надо его на расте переписать и всё починится.
> Сказано же "Раст безопасен!".
> Наверное дело в MSCode. Надо его на расте переписать и всё починится.Да, и autotools тоже, вместе с make, meson, и прочими, чтобы избавить их от возможности запускать произвольный код.
С этими достаточно просмотреть мейкфайл, чтобы убедиться в безопасности сборки.
> С этими достаточно просмотреть мейкфайл, чтобы убедиться в безопасности сборки.Хоть раз смотрел? (риторический вопрос)
>> autotools
> просмотреть мейкфайл*Теоретики-впопеннета-рука-лицо.жпг*
там лютая куча скриптов, которые генерят этот самый мейкфайл. Который сам по себе тоже совсем не маленький ...
Сюда уже захожу в комментарии чисто поржать. Эксперты оппеннета поражают своей компетентностью.Фактически проблема в сборке любого проекта, где запускается произвольный код с правами пользователя.
Любой make, cmake, autotools и т.п.
Здесь проблема просто вышла на другой уровень.Не просто собирать, но даже открыть файлы проекта.
>Фактически проблема в сборке любого проекта, где запускается произвольный код с правами пользователя.скачиваем курлом скрипт инсталлятора и перенаправляем сразу в шелл, а вы тут про систему сборки говорите :)
Так я и говорю - проблема не в скриптах. Проблема в Linux, в её древней модели безопасности из 80х годов "главное не root".Она устарела полностью. Из-за неё говорить о безопасности просто смешно. Что на десктопе, что на сервере.
Но тут эту поделку яростно защищают. Хотя можно было взять идеи Android и их улучшить.
> Хотя можно было взять идеи Android и их улучшить.Не надо, там через жопу. Особенно в 11+.
Ох, каждый первый дурак должен вылезти всех учить, потому как не в курсе о синдроме Даннинга-Крюгера.Вы _полностью_ некомпетентны. И лишь в качестве иллюстрации того, каким дураком быть не надо -- иллюстрация этого остаётся здесь болтаться.
Потому как человек хотя бы с пониманием основ затронутого вопроса говорил бы не о правах, на которых выполняется код, а о том, что приводит к выполнению произвольного кода -- здесь первично именно это.
> Хотя можно было взять идеи Android
...построенного на Linux. Занавес.
Батенька, да вы идиот однако. И подтверждение это - от вас никакой конкретики, только патетика.В Android своя модель безопасности, своё кастомное ядро Linux, своя libc библиотека bionic, и так далее.
У приложений в Android нет доступа ко всей файловой системе пользователя. Приложения Android должны запрашивать доступ к ФС (не ко всей), к контактам, календарь и другой чувствительной информации. Разрешение можно всегда отозвать.
Батенька, ну куда вы с таким уровнем в споры взрослых дяденек?
И только круглый идиот не понимает что любая, абсолютно любая программа не написанная лично вами (со всеми зависимостями) есть суть выполнение произвольного кода. Который надо максимально ограничивать.
Просто в 80е годы никаких программ и не было, практически. Нужно было защищать мейнфрейм / суперкомпьютер. А проблема была всегда.
Прикинь, андроид тупо создаёт классического юниксового юзера под каждую аппку? А для работы с файлами в 11+ нужно перепимывать приложение, потому что там кагбе уже и не файлы, а некоторый их заменитель предоставляется черезжопно и тормознуто и юзеру каждый раз при открытии нового файла надо разрешение выдавать. И сишные либки с этим говном не работают без переписывания.
Серьезно? Если это так - это ужас на крыльях ночи. Костыльное говнецо.Но я скорее про высокоуровневую идею -доступ по приложениям, а не как в стандартном linux.
А имплементация может быть говном, не спорю (не знаю).
> Проблема в Linux, в её древней модели безопасности из 80х годов "главное не root".дыркер все исправит :) песочница для системы сборки
>идеи AndroidЯ там что-то ни одной хорошей идеи не видел, учитывая то, что второй раст от гугли тоже привязан к системе сборки.
Да, смотрю, а что? В мелких проектах нет никакой кучи, а большие уже опакечены в моём дистре. У меня же не каргой это всё автоматически качается и запускается, не так уж и часто надо смотреть.
> Да, смотрю, а что? В мелких проектах нет никакой кучи,Мелкие - это калькуляторы? Потому что даже в i3 configure - под 12 тыщ, а сгенерированном Makefile - под 4 тыщи строк.
> а большие уже опакечены в моём дистре.
Да, и поэтому открывать большие проекты нужно только растовым смузихлебам ... ну и волшебным гномикам для опакечивания и сборки пакета, но на то они и гномики ...
> У меня же не каргой это всё автоматически качается и запускается,Классический опеннетный уровень "владения предметом" уже был продемонстрирован, в повторной демонстрации нет никакой необходимости.
А в мейкфайле ядра линукс < 2K строк, и шо? Сравнимо с размером срачика под этой новостью. Мелкие - это мелкие тулзовинки или демки, i3 скорее всего опакечен в opensuse и собирать его не нужно.
> А в мейкфайле ядра линукс < 2K строк, и шо?шо?
$ find /usr/src/linux/ -name Makefile | xargs wc -l
...
37 /usr/src/linux/init/Makefile
65998 итогоЭто только Makefile'ы, а там ведь есть ещё код всякий, который в процессе сборки используется, всякие там oldconfig, menuconfig, статические анализаторы, генераторы депендансов... В ядре своя собственная система сборки, в которой make используется как вспомогательная утилита.
> А в мейкфайле ядра линукс < 2K строк, и шо?
$ find linux-5.12.4 -name Makefile | wc -l
2607
$ find linux-5.12.4 -iname "Makefile*" |xargs wc -l|tail -n3
57 linux-5.12.4/scripts/Makefile.kasan
491 linux-5.12.4/scripts/Makefile.lib
73691 total$ find linux-5.12.4 -iname "*.sh" | xargs wc -l | tail -n3
22 linux-5.12.4/scripts/gcc-goto.sh
102356 total
$ find linux-5.12.4 -iname "*.pl" | xargs wc -l | tail -n3
171 linux-5.12.4/scripts/headers_check.pl
98 linux-5.12.4/scripts/checkincludes.pl
40246 total
Шо ты теоретик^W настоящий опеннетчик я уже понял ...> С этими достаточно просмотреть мейкфайл, чтобы убедиться в безопасности сборки.
> i3 скорее всего опакечен в opensuse и собирать его не нужно.Вот он, настоящий опеннетчик, для которого опенсурс - не о доработке софта под себя (наложением патчей или недефолтными опциями сборки), а о том "как в венде, только на халяву и чтобнитакойкаквсе!" *лицодлань*
Еще раз: сабжевая "уязвимость" - только для тех, кто решит хотя бы открыть код в IDE.
Но обычно, открывшие в _IDE_ - его еще и собирают, при этом запуская целую тучу скриптов. И на практике "контроль" билдскриптов "правильных" систем сборки - тот же геморрой, только в профиль.Поэтому и *Теоретики-впопеннета-рука-лицо.жпг*
Проблема и маленькая и большая одновременно и касается она ЛЮБОЙ прграммы, в которой юзаются плагины, редактор текста, кода, файловый менеджер...
Попробуй воспроизвести ее в vifm.
я легко воспроизвожу это в vim - делаю шоткаты запускающие внешние exe-ники. В Емаксе вообще дочерта чего запускается.
Не корректно сказато что это дыра в редакторе. Корректно сказать что это дыра в аддоне для VScode который допускает утечки файлов и запускает не бог весть что при открытии файлов. Потому что ту же дыру можно сделать в другом редакоре через аддоны.
>Не корректно сказато что это дыра в редактореnotepad.exe в свое время запускал calc.exe :)
Вы, может быть, подумали, что это какое-то Undefined Behavior? Ничего подобного, Rust не допускает Undefined Behavior - всё так и задумано.
Это не новость, в JS при открытии проекта автоматически подхватывается файл линтера eslint. А это обычный JavaScript файл. Те фактически выполняется сторонний JS код.Теперь VS code спрашивает можно ли запускать этот файл, доверяете ли вы ему.
Поле для атаки огромное. И её никак не решить. Проблема не в редакторе.
Проблема в безопасности говнолинукса, который позволяет любому коду неявно запущенному от пользователя полезть в ssh и стырить все ключи.
А там будет доступ и к GitHub, и к AWS Cloud и считай доступ ко всей инфраструктуре компании.
Естественно эта атака делается на любой редактор. Включая vim.
Ну так запрети через SELinux сеому говнолинтеру шариться по системе, делов-то.
Показывает ущербность Линукса и подхода. Огромная дыра в безопасности много лет - "Запрети... через SELinux".Ты сам-то пробовал с ним работать? Я то пробовал. Это не инструмент для обычного пользователя, а для суровых админов, безопасников для серверных систем.
И насколько я помню там очень сложно написать правила и их надо писать под каждую программу?
И когда он только появился чтобы добавить правила для Firefox потребовалось НЕСКОЛЬКО ЛЕТ.
"Просто настрой SELinux" ахахаха
Сразу чувствуется opennet эксперт
Ну да, в других-то ОС такого конечно же нет, чтобы программы имели доступ к файлам пользователей?
Нет конечно.
В его любимой десяточке все программы плиточкой на экране выложены, никаких файлов там нет, что такое файлы?
id_rsa.priv? В десяточке? Окстись. 21 век, какой id_rsa.priv :)
Мне не интересно что в других системах. Мне интересно в Linux.А то что где-то также через ж сделано... аргумент из разряда "у соседа тоже насрано". Мне от этого ни легче, ни лучше. Утекают то мои ключики, а не соседские.
Не сами по себе утекают, а юзер запускает помойный софт, суёт в него помойные файлы и потом удивляется, что вышло не очень. При этом сделать нормально лень, на опеннетике же поныть куда проще?
Как ты определяешь "помойный" от "непомойного" ДО запуска приложения?))) Поделись секретным кунг-фу, пожалуйста.Ведь если запустить "помойный" софт хотя бы один раз... будет уже слишком поздно и ключики утекут.
По репутации. Когда речь идёт об npm, rust и связанных инструментах, очевидно что там всё запомоено.
При чём тут Rust и npm. Это для разработчиков.А глубже копнуть? Пользователь запускает приложение - как ты определяешь что он "непомойное"? Тоже по репутации?
А если в какой-то момент автор программы с отличной репутацией (но без денег) решил сп...слямзить все твои файлы?
Или ты ему сразу и на всю жизнь доверяешь? Доверять - передовая технология Linux и экспертов по безопасности с opennet.
В прошлом веке ещё в линукс были ограничения прав различных пользователей и возможность легко из текущего сеанса запустить процесс из под другого пользователя. Делаешь пользователя - помойку и не даёшь ему доступа к звенящим ключикам. И проблема решена.
Какие пользователи? Пользователь всего один. И у него много приложений, с разным уровнем доверия.Ну языком болтать про "легко" все горазды. Ты на деле покажи.
Я захожу в Ubuntu / Fedora под пользователем opennet. Как мне сделать так, чтобы к ssh директории имел доступ только два приложения GitHub cli и GitHub gui? А остальные при попытке - ругались бы?
Приложению по просмотру фоточек и их каталогированию я хочу дать доступ к папке Photos и ещё парочке, и ни к чему больше.А остальным приложениям к ФС, за исключением папок с фотографиями и ssh директории.
Жду ответа. Сразу же применю, раз это так легко, эти советы к своей системе.
Apparmor / selinux / flatpack.
Что ты мне названиями тыкаешь? Ты покажи как это легко? Конкретно, на примере.Flatpak... всё ясно, диванный теоретик. Даже не знаешь что Flatpak не предоставляет абсолютно никакой безопасности.
Держи, читай, получай знания https://flatkill.org/2020
А мне оно не надо, я ж не параноик. Шлакпак чужд идеологически, apparmor не нужен с момента удаления заведомо помойных прог. Открывальщики картинок должны открывать картинки по всей ФС, бровзеры должны уметь сохранять в любое место, и т.д. Под работу с потенциально помойным проприетарным софтом надо бы отдельного юзера выделить, но лень.
> Приложению по просмотру фоточек и их каталогированию я хочу дать доступ к
> папке Photos и ещё парочке, и ни к чему больше.
> А остальным приложениям к ФС, за исключением папок с фотографиямии когда понадобится выложить фотографию в веб или отправить почтой другому васяну - обломаться о то что у браузера или почтового клиента нет ведь доступа к секретной "папке" или "мамке" (я плохо разбираюсь в вашей терминологии, у меня в юникс-системах - каталоги) куда ходит "просмотр фоточек".
И так - с каждой ерундой.
> Жду ответа. Сразу же применю, раз это так легко, эти советы к
> своей системе.чрезвычайно легко. docker/lxc/да даже банальный chroot - средств примитивной изоляции процессов в этом вашем линухе понакорявкали больше чем надо было. (непримитивные, а-ля snap, не для конченных юзверей, там слишком много ненужных знаний требуется) Включая работающие целиком от непривиллегированного юзера, правда, как обычно, они-то самые небезопасные и есть.
Только пользоваться такой системой, как обычно, только дурак и захочет. Ну или совсем уж больной параноик.Причем чтобы ей именно пользоваться, а не др-ть как у него все сесюрно, а для работы дуалбутиком б-жественную десяточку, ему придется накостылить подпорок и shared bindings или аналогов - таки дающих разным программам доступ к одним и тем же файлам. И в конце-концов в них запутаться.
Единичный не то чтобы недоверенный, а просто не очень надежный процесс так запустить - да, можно, ничего не гарантирует, но уменьшает вероятность успешного pwning. Правда, желательно, чтобы это было что-нибудь безинтерфейсное, ибо проброс юзер интерфейсов через слои изоляции, опять же, способен свести всю безопастность к отрицательному значению - увеличив attack surface.
0) слово "приложение" предлагаю резко забыть. есть процессы,
у процессов есть UID и GID. это понятно ?1) а теперь сделайте так, чтобы:
1.1. процессы условно называемые "github_cli" и "github_gui" имели разные UIDы (но всегда одни и те же, при любом запуске), но один общий GID (всегда один и тот же, при любом запуске).
1.2. для группы с этим GID сделайте отдельную директорию .ssh_keys_for_github_only с правами "мне - все, github_GID - чтение и поиск, остальным - болт".
1.3. в директорию положите файл ключей с правами "мне - все, github_GID - чтение, остальным - болт".
1.4. научите "github_cli" и "github_gui" искать свои ключи в той директории в том файле.по-моему все.
Это не так просто, потому что нужно проследить чтобы у ресурсов "защищаемых" пользователей не были проставлены разрешения для other и в ACL. Тут только MAC или неймспейсы.
> По репутации.Яндекс не помойка получается....
Не то, что в богоспасаемой виндавс. Тот не только в профиль пускает, но и дает напихать полные Program Data и %windir% удаленных троянов и петь
Мне как-то глубоко наплевать что тамв Windows. Я сижу под Linux.И их проблемы мне не очень интересны.
Настолько глубоко, что даже линукс толком не знаешь?
Девляпс, не ты ли это?
Это мне рассказывают "эксперты", которую знают что-то про плиточку и %windata% в Windows?Ламерье, вы бы хотя бы так сильно не палились тут. Подрываете почётное звание "эксперт с opennet".
Девляпс, ну залогинься уже
Не заслужил ещё
правильнее сказать проблемы вообще нет. Но 99% коментирующих этого не поняли.
Хруст перенёс на этапы компиляции не только проверку на возможные уязвимости, но и сами уязвимости :D
_редактирования_. Этап компиляции - это каменный век какой-то!Зачем ждать компиляции, когда "умный" редактор кода может дать тебе клавиатурой по лапам прямо в процессе его набора!
Ну, или, вот... просто выполнить код неведомого васяна. А чотакова? Затобезопастно!
Истинно такЪ
Rust, vscode, безусловно запускающиеся макросы, фанатом которых является разработчик раста и продвигающий их как несомненное преимущество раста, в редакторе написанным на электроне от корпорации мелкомягких продвигающих раст и заодно внедряющих телеметрию во все дыре. В этой новости прекрасно все. Никогда ещё (часть) ит сферы настолько не деградировало.
На самом деле часть IT-сферы всегда деградировало, просто не всегда вокруг этой части удавалось создать такой хайп.
Проблема в Rust, а пишется что могут быть проблемы и в других местах. Это двойные стандарты! Надо прямо писать что нашли дыру в Rust!
согласен. #rustexploitmatter
> Проблема в Rust, а пишется что могут быть проблемы и в других местах. Это двойные стандарты!Да, надо писать что в других местах - ЕСТЬ проблемы! (Они же ж точно где-то есть, если даже скучный устаревший редактор не запускает никакой код при попытке посмотреть на исходник.)
а я говорил, что все дороги ведут в D
Уважуха, братуха
глобально и надёжно
Ну що, сынку? Помог табе твой раст?
Ну що, сынку? Помог табе твой раст?
А вообще да, вся новость сводится к стандартному:
"Если пользователь запустит на выполнение сторонний скрипт/плагин/бинарник, то тот может украсть/зашифровать/удалить файлы из его хомяка, ууууу! Теперь - банановый! Скрипт не в ФС, скрипт в макросе для исходников! УУУУ! Все в контейнеры и флатпаки!"
Дикие полотна configure.sh тоже работают до непосредственно сборки и прямо из консоли, но дурачки с опеннета будут заявлять что-то о расте :)
Эта "уязвимость" работает при вызове скрипта пакетного менеджера системы, компиляции произвольной либы на C || C++ || Rust || свой вариант или при запуске вообще _любого_ софта.
А тут просто ещё один интересный способ, что вызывает разве что лулзы, поскольку никакой безопасности и так нет даже на линуксах.
К тебе на улице могут подойти, набить морду и отобрать кредитку. Ты же не дурачок, должен понимать, что твоя безопасность и безопасность твоих данных и денег = 0, так что выложи тут номер карты, срок действия и CVV - хуже уже не будет. Это ведь всего лишь
> ещё один интересный способ, что вызывает разве что лулзы, поскольку никакой безопасности и так нет
Неудачный пример.
Подойти на улице можно приравнять к получить локальный доступ к устройству, где как бы уже ничего не поможет. В лучшем случае злоумышленник может удалить все твои данные, если не сумеет расшифровать.
Ну вот получил я локальный доступ к твоему телу, а у тебя нет кредиток, ка-зззел, за все как лох платишь кэшем , и кэша того кот накакал, мне даже на пивас не хватит, и мабила кнопочная, без банкклиента. В лучшем случае могу дать тебе в грызло лишний раз, похищения людей это другой бизнес, без меня, там совсем другие ставки.
Жесть, сейчас проверил, вскод даже в снап-версии ставится в классическом режиме
ты не поверишь, но это непопулярно https://github.com/microsoft/vscode/issues/75669только ручные профили для apparmor, только хардкор.
Ещё раз доказывает, что демократия/голосования в опенсурсе - это жёпа.
> Ещё раз доказывает, что демократия/голосования в опенсурсе - это жёпа.Да потому что вы, дол6ое6ы, когда копировали нашу республику, зачем-то решили дать голосовать - РАБАМ! Да кого ж интересует мнение гардероба или вешалки в прихожей, мать вашу?!
Имущественный ценз, возрастной ценз, бабы - чтоб на ую вертеть, а не в политику лезть - все вам уже было придумано и вполне успешно ведь реализовано.
Нееет, они за инклюзивность и права умственно-ограниченных!
А говорили rust надежный язык. Код еще не даже не скомпилировался, а уязвимости уже вылазят. Браво! Браво!!!
Раст и надёжный язык, что изменилось?
зря микрософт на гитхабе запрещает использование паролей, принудительно навязывая только ключи
Ничего не мешает запаролить ключи.
ничего не мешает оставить оба варианта, как было до покупки микрософтом
Это корпы и им неважно как тебе удобно. Им важно как они решили
Лол они это специально сделали. Просто майки пытаются делать хорошую мину при плохой игре против опенсорса.
Фрактал, ау! Ты где?!
Rustовая дырень
Всё еще в разы лучше типичной си дырени в рантайме
Раст ничем не лучше и не безопаснее других языков.
Смотря с чем сравнивать
Если с C/C++, то и лучше, и удобнее, и на голову безопаснее
А ты продолжай себе внушать :)
Раст хуже, неудобнее, менее безопасен чего стоят только его дыры в vscode, утечка памяти в фаерфоксе, утечки в редоксе, да везде на нем умудрились написать утечки, а система пакетов еще дырявее чем в npm.
А ты продолжай себе внушать :)
Вот зачем на этом ресурсе пропагандировать подобное? Теперь малодалекие будут цитировать эту статью
да какая разница, мелкие проблемы, которые скоро пофиксят, не мешают расту продолжать быть одним из лучших языков
> да какая разница, проблемы, которые лежат в основе всего в расте, которые поэтому никогда не пофиксят, не мешают расту продолжать быть одним из лучших языков по версии растомановпофиксил, не благодари
По версии любого, кто хоть немного в него вник, а не строчит на форуме всякий мусор.
Раст пора законодательно запретить. Чтобы малодалекие не писали ерунда про какую-то магическую безопасность, которая сама спускается на всех кто прикоснется к расту.
Не бывает ничего безопасного, но на фоне C/C++ это СУПЕР безопасный язык.
+
все познается в сравнении
> на фоне C/C++Надеюсь, раст его заменит.
В ближайшие 20 лет врядли. C++ только усиливает позиции.Node.js на C++ написан. Расширения нативные обычно тоже. Chrome и движок V8 тоже на C++ написан.
Новый JavaScript движок для React Native тоже на C++.
Те весь нижний слой JavaScript (самого популярного языка в мире) на C++.
Он никуда не денется. Новые базы данных тоже на C++. RocksDB, YugaByte, ...
Про игры вообще молчу.
нет такого языка C/C++. Или Си или Си++. Одно из двух
В расте дырень? Вот это да он же безопасный язык, как так-то а?
Где дырень? Он просто сделал процедурный макрос предусматривающий пользовательский код, туда можно запихнуть что угодно, бо это просто раст код.Это просто надуманная проблема, не более.
Скоро во всех растоманских IDE:
"Открытие этого rs файла может привести к краже злобными растоманами всех ваших ключей доступа, банковских карт и анальному рабству. Преварительно посмотреть файл нельзя, потому что это небезопасно. Вы действительно готовы к этому? [да] [нет]"
Для JavaScript проектов уже так (спрашивает про выполнение настроек линтера в проекте)
> Скоро во всех растоманских IDE:не умеешь ты писать ide, как мы поглядим... ну кто ж так делает-то? Работать как?
Пол-часа читать описание а потом еще мышью промазать и потерять пол-часа работы?!> "Открытие этого rs файла может привести к краже злобными растоманами всех ваших
> ключей доступа, банковских карт и анальному рабству. Преварительно посмотреть файл нельзя,
> потому что это небезопасно. Вы действительно готовы к этому? [да] [ok] [confirm] [always] [newer ask again]"И главное - при закрытии диалога крестиком или escape - тоже 'ok'!
(вдруг пользователь случайно не туда ткнул!)
В java проектах уже сейчас так. Idea спрашивает открыть его в безопастном режиме или в человеческом. А ведь java это не какие-то смузи хлебный rust, а энтерпрайз и банки.
>Проблема связана с раскрытием процедурных макросов во время начального анализа кода. Аналогичного эффекта также можно добиться во время компиляции с использованием команды "cargo build".Спасибо, Кэп. Все и так знали, что растоманы - смузихлёбы, и что их пакетный менеджер - говно.
Впрочем питонячий не лучше, но те хотя-бы работают над этим, уже стандартизирован полностью декларативный формат метаданных в pyproject.toml (а в форме setup.cfg он уже с конца 2016 есть), когда-нибудь setup.py можно будет просто запретить.
У них в срасте безопасность только на словах. Они уже даже не пишут в чем эта безопасность должна заключаться просто сферическая безопасность в вакууме.
"Демонстрация атаки на редакторы кода".. я слеп или в статье ничего кроме VScode не указано?
Список редакторов здесь https://microsoft.github.io/language-server-protocol/impleme.../GNU Emacs
vim8 and neovimно требуется rust-analyzer
Если говорить об эпичности новости, вопрос в том, насколько полно языковой сервер для Rust реализует спецификацию LSP.TextDocumentItem
An item to transfer a text document from the client to the server.
interface TextDocumentItem {
/**
* The text document's URI.
*/
uri: DocumentUri;
...
}Я правильно понимаю, что следующий фрагмент не пропустит некоторые URI scheme + authority:
let config = {
let root_path = match initialize_params
.root_uri
.and_then(|it| it.to_file_path().ok())
.and_then(|it| AbsPathBuf::try_from(it).ok())
{
Some(it) => it,
None => {
let cwd = env::current_dir()?;
AbsPathBuf::assert(cwd)
}
};
или не правильно? =)
> Я правильно понимаю, что следующий фрагмент не пропустит некоторые URI scheme + authority, или не правильно?Не, не правильно. initialize_params -- это явно инстанс какого-то типа, не описанного в std, аргументы лямбд it тоже, я подозреваю, ссылаются на типы вне std. AbsPathBuf -- опять же не из std. Соответственно, можно конечно гадать по названиям идентификаторов о том, что этот код делает, но лучше не стоит, лучше сделать cargo doc и посмотреть в документацию.
То есть, что-то этот код отфильтрует конечно -- to_file_path, судя по всему, может сфейлится иногда (если метод ok следует сложившимся условностям именования методов, точнее если это метод библиотечного Result, конвертающий Result в Option), значит что-то он фильтрует. AbsPathBuf тоже может сфейлится, значит он тоже что-то фильтрует. Но что именно оно фильтрует? Ты можешь либо гадать на кофейной гуще, либо почитать в документации.
Повторяя же твою ошибку (гадая на кофейной гуще), я бы предположил, что здесь отбрасываются uri, которые ссылаются не на локальные файлы и которые не могут быть преобразованы в абсолютный путь к файлу. Если они отбрасываются, то вместо них подставляется env::current_dir (если, конечно, его удаётся получить и валидировать как абсолютный путь).
>> Я правильно понимаю, что следующий фрагмент не пропустит некоторые URI scheme + authority, или не правильно?
> Не, не правильно. initialize_params -- это явно инстанс какого-то типа, не описанного
> в stdВот-вот. Он описан в спецификации LSP. Это параметры инициализации сервера, которые отправляет клиент. Далее сервер производит с этими параметрами некие действия, которые в итоге приводят к исполнению кода, а располагается этот код по адресу root_uri (это корневой каталог "проекта").
Потому интересно, что может оказаться в root_uri.
Там может быть только file:///
или ещё и ftp://bhc-crew.org/perl-sploet.rsПотому что семантика TextDocumentItem подразумевает для описываемых URI сущностей (это не только корневой каталог, но и каждый анилизируемый файл) не просто open, а transfer (from the client to the server).
> я бы предположил, что
> здесь отбрасываются uri, которые ссылаются не на локальные файлы и которые
> не могут быть преобразованы в абсолютный путь к файлу.Именно это я и предположил, это действительно не более чем предположение. Может быть, что не отбрасываются? =)
Растоманство !
Предлагаю уже царю запилить свой язычок и пиарить, главное, надо нанять BLM для раскрутки.А пока не нанял, можно и Vala пиарить, такой же убийца сишарпа, как и раст, ток попроще.
Это скорее не новость, а забавное замечание того, что можно делать с "просто редактором", исполняющем сторонний код. В манжаре например конфигурационный файлик i3, лежащий в конфигах юзера (не etc), имеет права на чтение и запись юзером. Только внутри файла есть возможность добавлять шелловские команды на исполнение при запуске или бинды, которые в итоге исполняются от root. Имхо, такое можно почти в каждом приложении найти
> root. Имхо, такое можно почти в каждом приложении найтинет. далеко не все приложения, выполняющиеся от root, позволяют какие-то юзерские файлы, которые выполняют как код.
Некоторые написаны еще вменяемыми людьми, а не современными разработчиками "мне некогда читать документацию"А когда как код выполняется не предназначенное для выполнения - ну это проклятая сишечка и ее указатели небезопастные, вот как перепишут на хрусте - так выполняться будет прям при открытии кода в редакторе.
тут, кстати, нового прекрасного привалило:
https://ubuntu.com/security/notices/USN-4955-1https://bugs.launchpad.net/ubuntu/+source/rust-pleaser/+bug/...
безопастность хрустеров. Не знаю, осилит ли опеннет отдельную новость.
Юзеры г0вноподелия "VSCode" должны страдать. Скажем дружное "нахрен!" любым Жабоскриптным уродцам.
Всмысле демонстрация атаки?:))Я посмотрел код, он же просто сделал вызов нужного кода в процедурных макросах (макросах где сплошной раст код, ТУПО ЛЮБОЙ КОД)...
не, ребят) это надуманная атака..