Исследователи из Стендфордского университета, Калифорнийского университета в Сан-Диего и Техасского университета в Остине разработали инструментарий RLBox, который может применяться как дополнительный уровень изоляции для блокирования уязвимостей в библиотеках функций. RLBox нацелен на решение проблемы с безопасностью незаслуживающих доверия сторонних библиотек, которые не подконтрольны разработчикам, но уязвимости в которых могут скомпрометировать основной проект...Подробнее: https://www.opennet.me/opennews/art.shtml?num=52440
"не сильно медленнее" - эт насколько?
боюсь настолько же, насколько "почти не требуют дополнительных ресурсов"
Это значит что не надо покупать новые ресурсы мы доедим старые.
У меня для них есть более интересная идея. Переписать все на JS. Ведь он не тормозит, и такой супербезопасный, бла-бла-бла.
На надо сразу раскрывать все карты, юнга. Побьют жэж!
Сначала, пишем свой одновременно быстрый и безопасный язык, который не виноват в том что он тормозной. Это всё цена автоматическому управлению памятью(Огнелис - как пример). Не нравится - используй unsafe, хотя, не используй unsafe, ибо будет как с тем автором веб-фреймворка.
А потом главное - потихоньку подсыпать всё больше безопасности и разграничений.
> он тормозной. Это всё цена автоматическому управлению памятью
> автоматическому управлению
> [lifetime] analysis ... is done at compile timeИнтересно, какова цена очередной "анонимной экспердизы"?
> На надо сразу раскрывать все карты, юнга. Побьют жэж!В смысле раскрывать? Идея то баянная, они pdf.js же запилили. Правда кондовый critical vuln они тоже в нем запилили, вот ведь незадача. Да еще кроссплатформенно так, на зависть акробату.
По сути, "небезопасные" модули с применением описанной в статье штуковины и переписываются на "пережеванное" подобие JS, которым является WASM.
Ну а далее, этот код исполняется на существующем и, мб, чутка допиленном, JS-движке, как сильно минифицированный JS-код( привет, Wasm. Ходят слухи, что, из-за бОльшей компактности, код на нем сильно быстрее парсится ).
В оригинальной статье упор на то, что такой подход требует сильно меньше памяти, чем отдельные процессы. На опеннете почему-то упор на безопасность.
> В оригинальной статье упор на то, что такой подход требует сильно меньше
> памяти, чем отдельные процессы.А проца это сколько требует, интересно? Потому что столько телепанеий на каждый int...
>для изоляции выполнения библиотеки GraphiteНе надо было в библиотеку для рендеринга шрифтов впихивать свой ЯП, к тому же нестандартный.
>Механизм работы RLBox сводится к компиляции C/C++ кода изолируемой библиотеки в низкоуровневый промежуточный код WebAssembly
Видимо этот WASI никому не нужен, вот и приходится самим это говно жрать, чтобы менеджерам сказать "WASI очень нужен, теперь Firefox на него завязан". А результат один - Firefox будет ещё больше тормозить и жрать ещё больше памяти и электричества. Мне одного PDF.js вчера хватило, который систему в своп вогнал, пришлось перезагружать резетом. И на системе не 512 MiB, как некоторые тут могли бы нафантазировать.
Откройте для себя zram.
Сперва создадим себе проблем, а потом будем с ними героически бороться? Нет, zram хорошая штука. А вот файрфокс таки кривое и стремное блоатваре от окончательно свихнувшейся конторы, которая, видимо, очень хочет наконец забить на кодинг браузера и продать это каким-нибудь китайцам.
Сделайте одолжение - удалите firefox. Просто, чтобы не слушать бесконечное нытьё.
Праститя, удалив фуррятину на локалхосте вы не удалите её из остальной объективной реальности.
Но у вас есть возможность удалиться из объективной реальности самому.
> Сделайте одолжение - удалите firefox.Я это уже сделал, но мне тот факт что я сдуру насоветовал лису таки до сих пор икается, недовольными хомяками, которым гамадрила.корп уже не знающая чем заняться в очередной раз все изгадила и сломала. Например в 67 версии эти п-сы что-то поломали в скроллбарах. Не, действительно, нафиг нам скроллбары, когда тут высокие концепции дуром прут?! Еще немного и они достроят коммунизм. А кормить в пути никто не обещал, так что ежели вдруг у дорогого юзера да браузер опять стал неюзабелен, потерпите немного, это для вашего светлого будущего, ога :)
>Например в 67 версии эти п-сы что-то поломали в скроллбарахДа нормальные скроллбары, просто под цвет темы.
>>PDF.jsСие поделие сразу после установки браузера откручивать надо, как идеологически вредное. В любом браузере.
Сие поделие умело запускать ремотные JS с правами браузера, показав акроридеру мастеркласс на тему запиливания vuln'ов и эксплойтов к ним. Кроссплатформенный эксплойт - это было круто и инновационно, когда один и тот же код нагибает и макось, и винду, и линь, и на чем там еще вы это недоразумение смогли запустить.А то что эта дрянь в итоге жрет адовое количество памяти и тупит 5 минут если pdf был чуть более 2 страниц (в даташите может быть и мегов 30, более чем на 1000 страниц, но вебмакаки про это не в курсе) - и потом на раз вылетает по OOM (прожевать десятки мегов нагенеренного JS туго, сами понимаете) - пардон, мозилла, но ваши технологии КГАМ.
>Сие поделие сразу после установки браузера откручивать надо, как идеологически вредное. В любом браузере.Так?
pdfjs.disabled;true
Да можно просто другую открывашку выбрать и тогда он будет открывать пдфки системным просмотрщиком или просто сохранять.
Своп можно просто выключить и включить и он станет чистым. Перезагружаться для этого совсем лишнее если ты конечно не до конца завис.
1) Ребутнуть комп при активном своплении может быть быстрее, чем ждать пока это все отработает :)
2) Чтобы выключить своп, должно быть достаточно RAM в который все это выгрузится. А если свопом уже начали тарахтеть, значит с этим как раз проблема.
3) И даже если RAM все же найдется, то что выдавливание страниц из свопа будет быстро - ниоткуда не следует.Мне интересно, а аноним пробовал свой совет в ситуации с активным своплением? :)
1) Закрыть источник свопления?
2) Закрыть источник свопления? И место хватит во всех 640 килобайтах
3) Возможно это SSD так избаловал, но даже с HDD бывает такая медленная загрузка что проще почистить чем перезагрузиться. Хотя вот прям с секундомером не мерил бывают разные ситуации.
> 1) Закрыть источник свопления?Ага, если вы его знаете и смогли до него добраться за разумное время.
> 2) Закрыть источник свопления? И место хватит во всех 640 килобайтах
Его идентификация и/или форсированное убиение в тупящей системе может занять изрядно времени.
> 3) Возможно это SSD так избаловал, но даже с HDD бывает такая медленная загрузка
У лично меня с винча секунд 30 максимум. Идентифицировать и прибить проблемный таск за это время - разве что я точно знаю кто. А современные многопроцессные браузеры делают все это не таким уж пресным.
> Мне интересно, а аноним пробовал свой совет в ситуации с активным своплением? :)А мне интересно, где же обычный Пингви-Няшный пафос насчет общего технического превосходства над маздайкой в целом и как раз в отзывчивости при стрессе - в частности? :)
Маздайка вообще выгружает полбраузера в своп пока юзерь в ворд переключился. А когда назад - ых, ых, ых, вот тебе "превосходство", дорогой юзер.Ну и я тебе не пингвиняша, поэтому я таки последовал той идее с zram - у вообще нет свопа, так что у меня как раз комп быстрый и его принципиально не клинит надолго. Это не мешает потроллить блоатварщиков за жирнософт :)
Почему своп стоит вырубить?
- На HDD эмулировать оперативу кряхтением диска дико тормозно.
- На SSD это менее тормозно, но интенсивно протирает оный до дыр.А вот zram очень удачная идея - страницы кантуются между сжатой RAM и обычной. И вот это и реально быстро и ничего не протирается, но малоиспользуемое пожато, PROFIT. Но в винде всего этого, разумеется, нет. Так что тезис о превосходстве немного пролетает. Еще там вон аноним чего-то про время загрузки напрягается, мне кажется что у него тоже не пингвин, однако :)
На 10 увы, реализовано подобие zram, но лично вы можете верить дальше, что в 10 эта фича не реализована, а сам линукс ос для богов.
А сколько же у вас оперативной памяти, 1 гигабайт?
Вы сами сидите с маленьким количеством оперативы и ноете про плохое по.
Это так лицемерно...
Почему я думаю, что с маленьким? Иначе вы ба написали сколько её на вашей машине и не акцентировали внимание на числе 512.
Я пользовался Firefox, когда у меня было ещё 4 гига оперативы и все было хорошо.
Так что ваши крики и обвинения про плохой Firefox пусты и безосновательны.
Даже если и 1 гб это значит что софту можно расжиратся и оптимизировать не нужно? Ну чисто хомячье не особо умное.
Сидел когда-то с 512 памяти, хватало на все. Firefox плохой.
Библиотека в отдельном процессе? Отродясь такого не было.
Зачем тогда WASM?
чтобы потορмοзиллось немного
> Зачем тогда WASM?Чтобы эта библиотека не имела доступа к функциям ОС.
Про JS они уже так говорили, не помешало кроссплатформенному 0day отсканить винчи половине интернета.
Ну так примените что-то типа опёнковского pledge(2), и всё.Механизм изоляции под названием «процесс» давным-давно есть. Не понятно, зачем навороты? Пытаются сделать кроссплатформенное решение, что ли? Ну так им придётся функции ядра ОС по изоляции брать на себя. А это породит море проблем.
Спосибо за нескучные грофики. Моё вам увожение. Спосибо. Но нет.
"Спосибо за нискучные грофики. Маё вям увожение. Спосибо. На нит. "
Исправил, раз уж на то пошло
Миллениалы изобрели pledge(2) из OpenBSD?
Миллениалам уже за 40. Хм, т.е. за опенок маразматики топят?
В чем-то ты и прав)) Но с возрастом не всегда приходит разум, иногда возраст приходит один!
>т.е. за опенок маразматики топят?с подключением
Да, и ЕГО топят маразматики, не умеющие писать безопасный код.
За 30. С 1980 прошло ровно 40 лет и "за сорок" еще почти год не будет ни одного миллениала.Пздц опеннет, два числа отнять не могут.
Ну не, все ставят расширения! Какие хотят. А это уже навязано..
Первые два абзаца читаются ок, и тут...> Механизм работы RLBox сводится к компиляции C/C++ кода изолируемой библиотеки в низкоуровневый промежуточный код WebAssembly
facepalm.apng
А просто изолировать не получилось? Надо было wasm'ить? (а, ну так тут же "готовый инструментарий, чего стараться-то")
чем больше виртуализации и тормозов - тем лучше!
> I think you would find that doing this with just gcc/clang (so inside of C/C++, assuming no special compiler modifications) would be rather tricky to make work. But it’d be very cool to see!
Они таки придумали как сделать из си и плюсов Java :D. И мне кажется, мне таки придется посоветовать поставить хром знакомым хомячкам. Не потому что это хорошо, а потому что обтекать за то что насоветовал в свое время файрфокс я таки задолбался. Могу себе представить как какой-нибудь видеокодек будет работать, если там каждый int-чототам чикерить. Ухнет разика так в три, как ява, ибо int'ов там эвона сколько и они эвона с какой скоростью ворочаются, так что если там проверки делать - все и умрет к чертям собачьим. И будет у юзера вместо fullHD какой-нибудь 360p голимый. А юзеры начнут ныть "чтозанафиг опять лиса сломалась!!!111"
Истины ради asm.js вполне себе бегает почти как нативный, даром что там те же инты. Так что не все так плохо.
А просто не совать недоверенные библиотеки нельзя? Тем более, что раз они их могут скомпилировать во что попало - могли бы и проревьюить
> библиотека для обработки строк не сможет открыть сетевой сокет или файлЭто только в красочной маркетинговой презентации, а на деле, как обычно, библиотеки будут требовать права на записную книжку, доступ в сообщения, к микрофону и камере, и чтобы файлы все читались.
> Это только в красочной маркетинговой презентации, а на деле, как обычно, библиотеки
> будут требовать права на записную книжку, доступ в сообщения, к микрофону и камере, и чтобы файлы все читались.Можно предложить на выбор комбинации из /dev/urandom, /dev/zero, /dev/full, /dev/null, пиши-читай-доступай сколько угодно.
> Можно предложить на выбор комбинации из /dev/urandom, /dev/zero, /dev/full, /dev/null,
> пиши-читай-доступай сколько угодно.Там еще как раз в линухе модуль эмуляции камеры подогнали, вот как раз можно и затестить :).
А если сильно настаивать, я в принципе могу и обычный драйвер звуковухи немного пропатчить. Ну будет там не честное чтение с микрофона а выхлоп PRNG, слушайте его наздоровье :)
До тех пор, пока WASM это все (включая сеть и user interface) не не может, то могут обтребоваться. А как только по их просьбам WASM научится, то он станет ненужным звеном.
Главное, как всегда, что написано на расте. "Об уязвимостях можно больше не думать"
На JS они уже не думали об уязвимостях. И смогли таки в крутейший кроссплатформенный vuln.
unsafe в расте как всегда к безопасности
> unsafe в расте как всегда к безопасностиДело даже не в unsafe, он тут будет в любом случае, так как взаимодействует с сишным abi. Дело в позиционировании языка и создания из него некоего штампа безопасности, хайпа вокруг всяких блокчейнов и секурности. Для дргугих задач его даже и не рассматривают (не считая некоторых исключений), хотя это просто язык общего назначения, такой же как и C++.
> unsafe в расте как всегда к безопасности"Ну хоть что-то у нас в безопасности" (c) анекдот.
> Главное, как всегда, что написано на расте.Что написано на расте? RLBox, насколько я понимаю, написан на C++, иначе бы tainted<int> на картинке выглядел бы как Tainted<i32>.
Хуясте? Тут знаешь немного не так..не йазык красит человека))
Вот кстати действительно, могли бы Graphite на расте переписать и ходить гордо надутыми индюками. А не пытаться пофиксить "несекурное NIH" путём запихивания в WASM.
Graphite -- это язык описания шрифта, он выполняет шрифт как программу. Возможно шрифт загруженный из недоверенного источника. Чем тут поможет раст?
И много там выполнять? Глифов как-то конечное число, можно один раз проинтерпретировать и забыть. А по-хорошему - не повторять уроки постскрипта и не делать из картинки программу
> И много там выполнять? Глифов как-то конечное число, можно один раз проинтерпретировать
> и забыть. А по-хорошему - не повторять уроки постскрипта и не
> делать из картинки программуНе, ты не понял. Graphite -- это не замена Postscript'у или METAFONT'у. Он работает со строками и рендерит строки. А это убийственная задача в общем случае. Если ограничиться каким-нибудь одним языком, типа русского, то всё не так сложно. Но если попытаться выкатить единое решение для всех языков, то без скриптов под каждый язык+шрифт, ты не добъёшься ничего.
Загляни сюда
https://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id...
Кстати, неужели нельзя написать 1 скрипт для каждого языка и не клать его в шрифты, а клать в спец. папочку, и читать оттуда?
> Кстати, неужели нельзя написать 1 скрипт для каждого языка и не клать
> его в шрифты, а клать в спец. папочку, и читать оттуда?Если между шрифтами стандартизовано как из шрифта достать то или иное начертание символа (зависящее от контекста появления этого символа), то можно наверное.
Никак конечно же. Однако переписывание выглядело бы чутка полезнее (хотя бы для популяризации раста), чем wasm. Да и по своему опыту переписывания с одного япа на другой могу сказать, что в процессе можно переделать архитектуру на более оптимальную, да и баги иногда получается отловить.
> Никак конечно же. Однако переписывание выглядело бы чутка полезнее (хотя бы для
> популяризации раста), чем wasm.1. У раста с популяризацией всё ок. Оставь его в покое.
2. Популяризация языка, как повод для почёсывания NIH -- это ничего так мотивация для тех людей, кто занят разработкой этого языка или его популяризацией, для разработчиков же браузера -- это совершенно идиотская мотивация. Их задача браузер пилить, а не популяризировать язык или там памперсы рекламировать.> Да и по своему опыту переписывания с
> одного япа на другой могу сказать, что в процессе можно переделать
> архитектуру на более оптимальную, да и баги иногда получается отловить.Это да, но Graphite -- это не мозилловская разработка. И брать на себя ещё и разработку растовой реализации Graphite -- зачем? Затем ещё можно переписать libpng на rust'е. Да вообще пробежаться по депендансам к ff, и все их переписать на rust'е. Или можно научиться засовывать библиотеки в "нанопроцессы", изолировать их от внешнего мира, и меньшими усилиями достичь больших результатов в отношении безопасности.
А таки мазиле логично этим заниматься - чтобы вендорлокнуть побольше народа на себя. Вот только со стороны разработчика вляпываться в вендорлок таки заявка на залет.А так то круто
- Исходники вывалены, но только вот менять их нельзя :)
- Централизованая репка, залоченая на мозилу корп.
- Единственная реализация, завязанная на мозиллу.Пардон, даже для go есть например gccgo. А у этой шляпы условия настолько конские что даже так нельзя. И это, типа, не проприетарщина?
>Пардон, даже для go есть например gccgo. А у этой шляпы условия настолько конские что даже так нельзя. И это, типа, не проприетарщина?Можно. Только назвать это Cargo или Rust нельзя, ибо торговая марка. Та же история с фаирфоксом, но, вроде, никто проприетарщиной его не называл. Только вот зачем расту ещё один компилятор? Все эвристики и оптимизации gcc и clang предназначены в первую очередь для C++/C. Раст построен вокруг одного большого, сложно и оптимизированного для раста llvm-компилятора с линтерами и прочими, всё это требует большой работы. И gcc для раста "не пришей рукав", тем более что для допиливания под gcc требуется время и ресурсы, а выхлопа скорее всего не будет.
Как же они достали со всякими "инновациями". В наше время всё было лучше :-)
> RLBox нацелен на решение проблемы с безопасностью незаслуживающих доверия сторонних библиотек, которые не подконтрольны разработчикам, но уязвимости в которых могут скомпрометировать основной проект.Не использовать такие библиотеки, не? Особенно, если в основном проекта важна секурность.
>Не использовать такой браузер, ОС и компьютер, не?
В статье рассказано, что сделано это для типичных библиотек libjpeg, libpng, libtheora (еще специально указали, что в ней полно дыр), libvpx, libvorbis. По сути это замена NaCl с учетом, что решение уже может использоваться в apache и nodejs.Если честно, то ничего принципиально нового не изобрели. Все можно свести к тому, что дали решение, которое под капотом создает отдельный процесс, дает api из 5 функций и заставляет копировать данные перед тем как передать их из родительского процесса в дочерний, а потом еще раз скопировать результат из дочернего процесса обратно в родительский.
Надо радоваться, что хоть такое решение предоставили. Хотя самому сделать нечто аналогичное никто не запрещает, тем более что такая реализация уж больно очевидна в контексте данной задачи.
Не использовать никаких сторонних библиотек?
На самом деле не все поняли эту задумку. Кому-то даже было лень)) Ну, скучно т. е. Вот есть уБлок, все сторонние домены нах - работает! Потом можно включить парочку, если очень нужно.. пока ЭТИ еще не смогли добиться должного уровня рандомизации кода. Ну а потом вероятно будут другие блокировщики..
Что такое "нанопроцесс"? В ядре Линукс и других юникс-подобных ОС нет таких сущностей.
Скоро дойдем до того что отключение вебасембли в about:config приведет к не работоспособности всего браузера.
Ну так выкинуть такой браузер
Да давно уже выкинули.
Хехе, это как Поттеринг прибил шурупами свою системду к программам.
Для тех кому интересно короткий пересказ на русском обычной реализации (автор новости пересказ реализацию wasm, которую рекомендуют использовать когда есть уверенность в этом):
* песочные процессы (да это обычный отдельный процесс) построены на spinlocks + conditional variables + shared memory между песочницей и родителем
* бесконечное копирование данных из родителя в песочницу и обратно
* скорость вызова функций для spinlocks по их замерам в 20 раз медленнее
* еще медленнее вызовы в 300 раз, если бы реализация была только на conditional variables
* реалиазация песочницы заточена для систем минимум с 2 ядрами из-за особенности работы spinlocks
* замеры делались на топовой машине i7-6770k с 64гб озу, что ставит под сомнение разумность полученных выводов о том, как это хорошо и быстро летает
Стоп. Они добро на говно переводят, причём с увереным и заумным выражением лица.Ладно, я могу понять неспособность проанализировать бинарники, и тем более чужие. Но речь о сборке из исходников, когда на выходе есть и мап, и исчерпывающая отладочная информация.
Например у нас контроллер проверяет собственные обновление "на вменяемость".
Да, обновление и проверено, и подписано и даже своё, только контроллер далеко, и необслуживаемый, вот и приходится для всякой потенциальной пооблемы соломки подстилать.Хотя, даже голые бинарники можно успешно проверять. Да, это сложнене, но и результат совсем другого масштаба.
И кстати, моральное удовлетворение, выше чем от перевода быстрого кода на типа безопасные JS/Python.
Мозилла начинает и кончает. Очередное:Mozilla замораживает проект своего шлюза для умного дома WebThings Gateway. Такое письмо разослал Дэвид Брайант участникам проекта WebThings Gateway.
Она разве еще не кончила?! Пора уже!