В штатной утилите fsck для файловой системы F2FS, предназначенной для работы с накопителями на основе Flash-памяти, выявлены две уязвимости (CVE-2020-6105, CVE-2020-6108), приводящие к перезаписи областей памяти за пределами выделенного буфера при проверке специально модифицированной файловой системы. Уязвимости могут быть эксплуатированы для выполнение кода с правами суперпользователя во время проверки ФС. Проблемы устранены в пакете f2fs-tools 1.14...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=53896
"rust не нужен" говорили они
"C не дыра (в головах разработчика)" говорили ониах да, я же это уже писал.... регулярно.... повторение - мать учения?
а теперь пожалуйста пример кода на раст без unsafe при работе с файловыми системами.)))
Вот пример кода, который записывает несколько байт в файловый дескриптор №1. А уж его можно направить в файл файловой системы. Выглядит впечатляюще, но поверьте, это еще далеко не все возможности раста!fn main() {
println!("Hello World!");
}
Это не пример работы с файловой системой.
А запись в файл сделает уже другая программа, которая написана скорее всего не на Rust.
0:1 не в пользу Rust, round 2, fight!
> А запись в файл сделает уже другая программа, которая написана скорее всего не на Rust.А не ты очень умный, да?
$ ./rust-program >file
Не включайте дурака, за открытие файла и запись в него в данном случае отвечает не запущенна программа. Программа просто отработает и выплюнет в stdout текст и все, никакой работы с файлами тут нету
> Не включайте дурака, за открытие файла и запись в него в данном
> случае отвечает не запущенна программа. Программа просто отработает и выплюнет в
> stdout текст и все, никакой работы с файлами тут нету
> за открытие файла запись в него в данном случае отвечает не запущенна программаЗа открытие файла отвечает шелл. За запись отвечает программа, лол. Или по твоему за запись в дескриптор write()'ами тоже шелл отвечает? :D
Просили показать работу с файловой системой без unsafe
> За открытие файла отвечает шеллВот на этом вы сами поставили точку. Шелл вам все подготовил, значит задача уже провалена.
> Просили показать работу с файловой системой без unsafe
>> За открытие файла отвечает шелл
> Вот на этом вы сами поставили точку. Шелл вам все подготовил, значит
> задача уже провалена.Сделай open сам, кто тебе мешает-то? :D
> Просили показать работу с файловой системой без unsafe
fn main() {
println!("{}", std::fs::read_to_string("/etc/hosts").expect("Не шмогла я!"));
}
Или вон, оф. пример прямо из доков:
https://doc.rust-lang.org/std/io/index.html
use std::io;
use std::io::prelude::*;
use std::fs::File;fn main() -> io::Result<()> {
let mut f = File::open("foo.txt")?;
let mut buffer = [0; 10];// read up to 10 bytes
let n = f.read(&mut buffer)?;println!("The bytes: {:?}", &buffer[..n]);
Ok(())
}
Дальше-то что?
А потом мы берем, открывает исходники, и ищем unsafe внутри вызываемых функций из std::io или std::fs::File или std::fs::read_to_string.
Какой шанс что мы найдем unsafe?
> А потом мы берем, открывает исходники, и ищем unsafe внутри вызываемых функций
> из std::io или std::fs::File или std::fs::read_to_string.
> Какой шанс что мы найдем unsafe?И находим их в libc. Вопрос в том, что это меняет-то? Сам вызов std::fs::File вполне себе safe и наличие unsafe FFI вызовов не влияет на корректность программы, если сами FFI вызовы корректны. Я подозреваю, что не облажаться в десяти строках типа "дернули сискол и обернули в тип" авторы раста смогли.
>> А потом мы берем, открывает исходники, и ищем unsafe внутри вызываемых функций
>> из std::io или std::fs::File или std::fs::read_to_string.
>> Какой шанс что мы найдем unsafe?
> И находим их в libc. Вопрос в том, что это меняет-то? Сам
> вызов std::fs::File вполне себе safe и наличие unsafe FFI вызовов не
> влияет на корректность программы, если сами FFI вызовы корректны. Я подозреваю,
> что не облажаться в десяти строках типа "дернули сискол и обернули
> в тип" авторы раста смогли.Вот например, "страшный и ужасный unsafe в работе с файлами":
let fd = cvt_r(|| unsafe { open64(path.as_ptr(), flags, opts.mode as c_int) })?;
Страшно, да?
> "дернули сискол и обернули в тип" авторы раста смогли.(Комментаторы хором) Во-о-о-оот! Мы так и знали!
*Вариант анекдота про челябинских лесорубов и японскую бензопилу*
> А потом мы берем, открываем исходники, и ищем знакомые слова внутри, попутно додумывая "как оно там на самом деле работает", делая при этом умный и загадочный вид в комментариях!Поправил, не благодарите.
> Не включайте дурака, за открытие файла и запись в него в данном
> случае отвечает не запущенна программа. Программа просто отработает и выплюнет в
> stdout текст и все, никакой работы с файлами тут нетуПросвещайся, лалка:
$ cat test.c
#include <err.h>
#include <stdio.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <unistd.h>int
main(void)
{
struct stat st = {0};if (fstat(1, &st) == -1)
err(1, "failed to stat stdout");printf("inode = %d\n", st.st_ino);
return 0;
}
$ gcc -o test test.c
$ ./test >lol
$ cat lol
inode = 4108440
$ stat -c 'inode = %i' lol
inode = 4108440
$ cat lol
inode = 4108440
Каюсь, был не прав. Но зато как мы быстро перешли к Си!
Один фиг файловый дескриптор просто так из воздуха не появляется
> Каюсь, был не прав. Но зато как мы быстро перешли к Си!Ну раста-то ты не знаешь.
> Один фиг файловый дескриптор просто так из воздуха не появляется
Нет, он появляется через open(). В расте open делается так:
let mut file = File::open("foo.txt")?;
Покажи мне, пожалуйста, unsafe.
ну он может скрываться внутри вызовов File::open, тут надо смотреть исходники
> ну он может скрываться внутри вызовов File::open, тут надо смотреть исходникиОн точно скрывается в вызовах крейта libc, вопрос в том, что скрывается он там причинам довольно тривиальным -- FFI.
Т.е. возвращаясь к исходному вопросу
> а теперь пожалуйста пример кода на раст без unsafe при работе с файловыми системами.)))Отдельно замечу - корректность кода в unsafe не рассматривается, вопрос был в наличии unsafe.
unsafe конкретно в работе с файлами нет. Т.е. функции, которые ты дергаешь (std::File::open, например) -- safe. Есть unsafe блоки при работе с libc, но у тебя как бы не вариантов -- любой FFI вызов (в том числе asm) это unsafe просто по определению -- ты передаешь работу ядру/другой библиотеке/etc.
Ну как бы о чем и была в начале речь, без unsafe вы не можете открыть файл.
Я хз зачем так яростно отстаивать или оправдывать неверную точку зрения.
> Ну как бы о чем и была в начале речь, без unsafe
> вы не можете открыть файл.
> Я хз зачем так яростно отстаивать или оправдывать неверную точку зрения.Потому что разговор шел в контексте очередной сишной дыры с памятью.
Ну я прицепился к тому, что без unsafe можно с файлами работать.
imho низкоуровневые вещи типа драйверов и прочих все таки еще за C/asm, rust там делать пока что нечего.
Мб в будущем ситуация поменяется, но пока так.
> imho низкоуровневые вещи типа драйверов и прочих все таки еще за C/asm, rust там делать пока что нечего.Откуда этот вывод-то?
+потому что в этой области придется обмазаться unsafe по самое немогу. Если я правильно понимаю, часть гарантий раста сохранится,но лишь часть.
+сильно сомневаюсь, что будет достигнут паритет по скорости с С в данном случае.
+через годик другой посмотрим, мб они собственный компилятор и runtime таки доделают. Слишком сырой еще язык
> потому что в этой области придется обмазаться unsafe по самое немогу.И этот вывод сделан откуда? В работе с файлами, как мы только что выяснили, unsafe присутствует только в одном месте -- FFI (либо raw syscall, либо вызов в libc). Весь остальной код safe.
> Если я правильно понимаю, часть гарантий раста сохранится,но лишь часть.
Если твой unsafe блок содержит только FFI вызов, то сохраняются все гарантии. Потому что unsafe это всего лишь блок кода, где разрешены определенные вещи (raw pointers, например, или вызов ассемблерной/сишной функции). Твой растовый код ниже по стеку не становится менее надежным от этого.
> сильно сомневаюсь, что будет достигнут паритет по скорости с С в данном случае.
Мьютексы в расте быстрее, чем pthreads. rustls, которая TLS библиотека, быстрее openssl и жрет меньше памяти.
Я про область написания драйверов, т.е. прямая работа с железом.
Вы наверное специально проигнорировали это, привели левые примеры, с некорректным сравнением.
Вести дискуссию с такими приемами я не хочу, поэтому самоотстраняюсь.
> Я про область написания драйверов, т.е. прямая работа с железом.
> Вы наверное специально проигнорировали это, привели левые примеры, с некорректным сравнением.Признайся, ты драйвера в глаза не видел.
> Т.е. возвращаясь к исходному вопросу
>> а теперь пожалуйста пример кода на раст без unsafe при работе с файловыми системами.)))
> Отдельно замечу - корректность кода в unsafe не рассматривается, вопрос был в
> наличии unsafe.unsafe конкретно в работе с файлами нет. Т.е. функции, которые ты дергаешь (std::File::open, например) -- safe. Есть unsafe блоки при работе с libc, но у тебя как бы не вариантов -- любой FFI вызов (в том числе asm) это unsafe просто по определению -- ты передаешь работу ядру/другой библиотеке/etc.
а он и не выключал.
огнепоклонники раста так и не поняли, что вся эта хваленая безопасность раста только в программах не касающихся работы с памятью и железом. что впрочем не так уж и мало, но никак нельзя претендовать на язык системного уровня. да с unsafe можно влезть и в системный уровень, но тогда все отличие раста от таких как с/с++ пропадает. все дело в том, что работа с системными ресурсами сама по себе не безопасна и требует знания и понимания. Чего в последнее время хотят избежать(разработчика быстрее и дешевле подготовить) , отчего и весь этот вой о безопасности или не безопасности языков. но на системном уровне нет абсолютно безопасных языков. вот и все.
>огнепоклонники раста так и не поняливот же тупые. Судя по неспособности смузихлебов написать программу работы с файловыми системами без unsafe их недоязык даже операции с файлами не может без него выполнять.
Настоящие программисты как писали на чистом Си, так и пишут.
> огнепоклонники раста так и не поняли, что вся эта хваленая безопасность раста
> только в программах не касающихся работы с памятью и железом. что
> впрочем не так уж и мало, но никак нельзя претендовать на
> язык системного уровня. да с unsafe можно влезть и в системный
> уровень, но тогда все отличие раста от таких как с/с++ пропадает.
> все дело в том, что работа с системными ресурсами сама по
> себе не безопасна и требует знания и понимания. Чего в последнее
> время хотят избежать(разработчика быстрее и дешевле подготовить) , отчего и весь
> этот вой о безопасности или не безопасности языков. но на системном
> уровне нет абсолютно безопасных языков. вот и все.вон там выше в новости ошибка при работе с железом? или ошибка при работе с обычным масивом, которая не требует unsafe?
зы: для чего требуется unsafe при "работе с памятью" ? на сколько я знаю - там приходится делать ансейф только в случаях когда алгоритмически нельзя сделать однозначное владение (например, связаный список)
fsck утилита однозначного и полного владения памятью, в данном случае памятью флеш накопителя, при этом она еще и форматированием занимается. напиши без unsafe. я не говорил что раст плохой язык в пространстве пользователя для выполнения обычных задач и даже с unsafe для работы с железом. но при использовании unsafe он теряет все свои преимущества и становится на один уровень с с/с++.( хотя я считаю это просто уровень программистов низковат вот и делают ляпы не проверив). просто идолопоклонство неуместно. это еще один язык. если уж на то пошло то я бы выделил D.
любому нормальному программисту это очевидно.
>fsck утилита однозначного и полного владения памятью, в данном случае памятью флеш накопителяпочему?
> но при использовании unsafe он теряет все свои преимущества и становится на один уровень с с/с++.А все почему? А все потому что гладиолус!
(советую ознакомится с матчастью, а не следовать древней местной традиции выискивания взглядом знакомых слов и додумывания "как оно там должно работать")
вам само название unsafe ничего не говорит? нет? ну ладно. это незащищенный от ошибок режим, опасный короче)))) так вам наверное станет яснее. нет я в курсе что раст может проводить операции с файлами в защищенном режиме, но fsck это не операции с файлами -0 это операции с самой файловой системой, требующей доступ к самому железу, а в расте с этим однозначно потребуется работа через unsafe. повторяю не работа с файлами, с самим железом.
>> ознакомится с матчастью, а не следовать древней местной традиции выискивания взглядом знакомых слов и додумывания "как оно там должно работать"
> вам само название unsafe ничего не говорит? нет? ну ладно. это незащищенный от ошибок режим, опасный короче))))---
The only things that are different in Unsafe Rust are that you can:Dereference raw pointers
Call unsafe functions (including C functions, compiler intrinsics, and the raw allocator)
Implement unsafe traits
Mutate statics
Access fields of unionsIt’s important to understand that unsafe doesn’t turn off the borrow checker or disable any other of Rust’s safety checks
---> так вам наверное станет яснее. нет я в курсе что раст может проводить операции с файлами в защищенном режиме, но fsck это не операции с файлами -0 это операции с самой файловой системой, требующей доступ к самому железу, а
> в расте с этим однозначно потребуется работа через unsafe. повторяю не
> работа с файлами, с самим железом.Яснопонятно. Очередной опеннетный Эксперт по системному программированию в целом (и по ржавчине в частности)
Хинт: читать поблочно из /dev/*блокдевайс*/ можно даже на жопоскрипте.
Сразу видно человека который хорошо разбирается в языках программирования
Отварите пожалуйста мне на вопрос, для общего развития, чем отличается запастись и чтения в файл, от записи и чтения в файл блочного устройства флешки, например /dev/sdb
Получается если в в файл устройства без unsafe писать нельзя то и в обычные файлы тоже нельзя?
> Сразу видно человека который хорошо разбирается в языках программированияОбращайтесь.
> Отварите пожалуйста мне на вопрос, для общего развития, чем отличается запастись и чтения в файл, от записи и чтения в файл блочного устройства флешки, например /dev/sdb
Ничем и многим
(есть нюансы, но мне лень гадать, на что "типа намекает" очередной комментатор. Факт в том, что в никсах
cat /dev/sdb|od -tx1
демонстрирует мифический "прямой доступ к железу".
Впрочем, в винде, если не "соптимизнули" в новых версиях, то не намного сложнее - CreateFile(PhysicalDrive-что-то-там), читай и пиши - не хочу.
)> Получается если в в файл устройства без unsafe писать нельзя то и в обычные файлы тоже нельзя?
Получается, если нафантазировать про unsafe в целом и работу ржавчины с устройствами в частности, то многое будет нельзя. Или можно - тут уж от фантазии зависит.
> я бы выделил D.почему его?
Это наверное просто вы сами ниасилили со своим Си-головного-мозга или просто найти не смогли. Всё там хорошо. Учите матчасть.
Что значит пожалуйста? А платить кто будет? 15 млн. не меньше ваша просьба стоит
Ну не неси чушь, а? Bounds checking прекрасно делается в любом языке. И тормоза от него - тоже в любом языке, почему обычно и не используется.
> Ну не неси чушь, а? Bounds checking прекрасно делается в любом языке.
> И тормоза от него - тоже в любом языке, почему обычно
> и не используется.в расте 3/4 bounds checking - времени компиляции, не?
Не-не.
Если у тебя вместо массивов, указатели на неопределенную область памяти без границ, как в самом лучшем языке всех времен, то проверку на выход за границы ты не сделаешь
> Если у тебя вместо массивов, указатели на неопределенную область памяти без границ,
> как в самом лучшем языке всех времен, то проверку на выход
> за границы ты не сделаешьа зачем такая неопределённая область памяти то??
драйвер всегда знает чего и сколько он запросил и получит от железа
надо только принудить программиста вписать проверку на размер
rust с этим справляется, а C - нет
> надо только принудить программиста вписать проверку на размер
> rust с этим справляется, а C - нетИ как сие принуждение избавляет от ошибок при "вписывании" проверки границ?
Жесть какая. А если у меня попадание указателя в выделенную память гарантируется алгоритмом, всё равно тратить такты на проверку?
> Жесть какая. А если у меня попадание указателя в выделенную память гарантируется
> алгоритмом, всё равно тратить такты на проверку?в расте компилятор (по слухам) умеет достаточно неплохо вычислять диапозоны значений и может выпиливать провеоку в компайлтайм
Не только раст так умеет, java тоже например, но там это работает только в простейших случаях типа такого for(int i = 0; i < array.length; i++) some(array[i]). Более продвинутый ли анализатор в расте - сомнительно, разработка технологий не должна полагаться на верования. Действительно продвинутый анализатор позволил бы писать как в языках с автоматическим управлением памятью, но с управлением ей во время компиляции.
Даже если и предположить что Раст может защитить от случайной уязвимости, что не так. Как Раст защитит от уязвимости которую автор кода добавил специально?
> Как Раст защитит от уязвимости которую автор кода добавил специально?не мешайте тёплое с мягким!!
И что тогда от fsf останется?
> повторение - мать учения?Это кому как. Людям, отрицающим уязвимости линукса и доказывающим что они не уязвимости, потому что они веруют в догму, что линукс неуязвим, можно хоть кол на голове тесать, и всё равно никакая мать не поможет им научится.
Kuzma's mother?..
> Kuzma's mother?..Я достаточно точно выразился: никакая мать не поможет. Мышление выправить себе можно только самостоятельно, тут _ничто_ не поможет.
https://www.opennet.dev/openforum/vsluhforumID3/122119.html#96Раст не нужен.
С нужен.
Ядра ОС которые некорректно выделяют память не нужны, как и дистры которые их используют.
Повторяй, заучивай.
фрактал,.. как ты уже надоел в каждой теме свой фанатизм выпячивать. почему тебе не др***я на руст одному? обязательно нужно всем показывать свою "инклюзивность"?
А то раст не дыра? Ещё какая - на гитхабчике вашего любимого раста 5к+ багов висит, а тут 1 нашли - и сразу кудахтать.
https://github.com/rust-lang/rust/issues
Раст безопасен говорили они. На расте легко писать говорили они.Они говорили и говорили. Но так ничего и не написали.
Ах нет, написали. Приветсвенное окошко для гнома. Супер.
> ах да, я же это уже писал.... регулярноне пробовал вместо комментариев на опеннете код писать? показал бы всем, как надо
Ждём визжащих про неправильных программистов сишников.
"При этом для эксплуатации уязвимости атакующий должен иметь физический доступ к накопителю или временно получить права root для записи на уровне блочного устройства."Ага, чтобы получить root, нужно сначала получить root. Отличная уязвимость.
Так через флэшку же можно или ещё как.
В смартфоне ч/з флешку? Круто.
По моему уже все смартфоны умеют OTG. Через него можно подключит флешку.
> Через него можно подключит флешку.Чтобы взломать или зловреда посадить?
> Чтобы взломать или зловреда посадить?Посадить зловреда, который сольёт все ключи и пароли, а так же предоставит полный удалённый доступ и прокси-сервер злоумышленнику.
Зачем ему сажать зловреда от рута, когда у него итак есть рут и ещё и флешка вставлена ?
Зачем злоумышленнику root? Yеужели Ваша DE требует пароля при подключении флешки?
Как запустить fsck флешки на телефоне если там просят пинкод?
Почему только смартфон? F2FS доступна только на смартфонах?А вообще да, это, например, путь к root-ованию. Или это путь ко взлому телефона вашей жены (для установки туда программ-шпионов)
Часто телефон можно увести в специальный режим, позволяющий читать/писать флешку.
Или выпаять её и переписать на программаторе.Тогда телефон выполнит код злоумышленника во время загрузки, и вся хитроумная схема с запрятыванием неизвлекаемого ключа в аппаратное хранилище станет бесполезной.
" Ключевые слова: f2fs, fsck, f*** "
Астрологи объявили неделю уязвимостей в линукс
При этом любая эксплуатация "уязвимости" в Linux (а также процесс заражения зловредами) начинается с ввода в консоли su или sudo, далее пароля рута, и понеслось.
Инженеры из компании Google выявили серьёзную уязвимость (CVE-2020-12351) в свободном Bluetooth-стеке BlueZ, используемом в дистрибутивах Linux и Chrome OS. Уязвимость, которой присвоено кодовое имя BleedingTooth, позволяет неавторизированному атакующему без участия пользователя организовать выполнение своего кода на уровне ядра Linux через отправку специально оформленных Bluetooth-пакетов.Где тут команда sudo? Проверки файловых систем в Linux происходят так же автоматически, как и автозапуски в WinXP.
> специально оформленных Bluetooth-пакетовКто-то держит включенный Bluetooth, скажем, на ноутбуке? Ну чепуха же.
Где вижу опасность уязвимости, это в смартфонах для подключения беспроводных гарнитур и автомобильных мультимедиа системах для подключения опять же смартфона. Но речи о них не шло.
> Кто-то держит включенный Bluetooth, скажем, на ноутбуке? Ну чепуха же.Где то он не включен по умолчанию? Или каждый пользователь Linux это компьютерный гуру? Если бы это было так, то дистрибутивы были бы не нужны.
Связываю телефон с компьютером через блютуз для звонка через компьютер. Так что да, держат.
Кажется Apple держит. По крайней мере на планшете он не вырубается. Точнее вырубается, но на следующий день они заботливо его включают, а то глупый юзер забудет включить и будет возмущаться.
Не врубается сам, легко можно нечаянно включить, но новость с уязвимостью про другую систему
>и добиться выполнения своего кода с повышенными привилегиями на этапе загрузки, что может использоваться для обхода механизма верифицированной загрузки AndroidТак это же хорошо. Загрузчики и андроиды рутовать можно
Вот и китайский товарищмайор так же думают, а то палкувжоппу, как у вас, рюйских - фу как негигиенично!Специальную флэшку через otg чпок - и ты ему можешь уже ничего не разблокировать.
Виноват, конечно, сасунг, неправильный си, кто угодно кроме модных-современных тенденций думать за пользователя (надо ли ему вообще монтировать флэшку с f2fs внезапно появившуюся в его смартфоне, и тем более - еще и fsck запускать). Он же ж - т7пой, нельзя ему ничего решать.
F2FS эта та самая файловая система, которая до сих пор не стабилизировала свой формат?
Нет, то была другая.
Это btrfs,до сих пор.
ЧТо за чушь?The filesystem disk format is stable: https://btrfs.wiki.kernel.org/index.php/Main_Page#Stability_...
Там же: "The Btrfs code base is under heavy development."
Это, в общем-то, всё, что нужно знать про Btrfs, разрабатываемую с 2009 года.