LINUX.ORG.RU

Rust is not safe!

 ,


1

7

https://youtu.be/vfMpIsJwpjU

Для Ъ: в этом вашем Rust с 2015 года существует уязвимость, позволяющая неограниченно расширить время жизни любой переменной и воспроизвести любые уязвимости, связанные с памятью.

Это уже вторая подобная уязвимость, первая была, когда люди стали эмулировать сырые указатели с помощью индексов в массивах.

А Linux тут при том, что и на нём эти уязвимости прекрасно воспроизведутся.

★★★★★

Последнее исправление: Dimez (всего исправлений: 3)

Ответ на: комментарий от hateyoufeel

Проблема в том, что там нет многих штук, которые сегодня считаются довольно базовыми для ЯП. Например, пакетного менеджера и общего репозитария библиотек.

У кого? У хипсторов воспитанных рейтингом тиобе? Это из-за них адакоре в аду тянут эту херь «алире»? Тоже проблему нашли. А потом шагу без репозитория ступить не могут.

slackwarrior ★★★★★
()
Ответ на: комментарий от slackwarrior

Проблема в том, что там нет многих штук, которые сегодня считаются довольно базовыми для ЯП. Например, пакетного менеджера и общего репозитария библиотек.

У кого? У хипсторов воспитанных рейтингом тиобе? Это из-за них адакоре в аду тянут эту херь «алире»? Тоже проблему нашли. А потом шагу без репозитория ступить не могут.

Больше гнилого илитизма богу илитизма! Что? Захотели чтобы все зависимости подтягивались автоматом, да версии с хешами сверялись? Воспроизводимые сборки, вплоть до последнего байта в бинарнике? НЕТ! ДИДЫ СТРАДАЛИ И НАМ ЗАВЕЩАЛИ!

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

Если форматная строка константна, то даже gcc умеет проверять это говно сейчас.

Даже если константна. Гарантировать, что в данных, переданных для %s, достаточно близко есть 0, он разве умеет? И что результат влезет в предоставленный буфер.

monk ★★★★★
()
Ответ на: комментарий от intelfx

И что? В свое время он был aaa-шутером, изменившим мир и положившим начало гей-мингу как массовому явлению… Он настолько примечателен что порт на котором висит его сервер официально зарегистрированы и тп. Это первое что пришло в голову. А что ты мне это растоговно показываешь ни о чем не говорит - дум уже и на похапе портировали

rtxtxtrx
()
Ответ на: комментарий от hateyoufeel

Сто раз говорили. Твой айпишник внесут в черный список, пардон, заблокируют на сервере репозитория, и что тогда делать с твоим удобством? Троянский конь, не иначе.

Более-менее работающая схема, это когда библиотеки идут на отечественном дистрибутиве. Ну, в самом крайнем случае, если они уже лежат в своем собственном nexus. А если уж совсем припрет использовать растишку, то пусть библиотеки лежат локально через cargo vendor.

Тем не менее, долгоживущий вариант - это именно библиотеки из подконтрольного дистрибутива.

А что касается этого вашего обожаемого троянского коня в виде пакетных менеджеров, то наплачитесь вы с ним еще!

anonymous
()
Ответ на: комментарий от monk

Гарантировать, что в данных, переданных для %s, достаточно близко есть 0, он разве умеет? И что результат влезет в предоставленный буфер.

Это уже из серии сишной работы со строками. Это не проблема sprintf, это проблема сишных строк в принципе (и отсутствия валидации входных данных). Так можно сказать, что strlen() тоже не безопасен, потому что так и есть.

hateyoufeel ★★★★★
()
Ответ на: комментарий от anonymous

Сто раз говорили. Твой айпишник внесут в черный список, пардон, заблокируют на сервере репозитория, и что тогда делать с твоим удобством? Троянский конь, не иначе.

Воспользуюсь зеркалом? Их есть, анон. Не тупи.

Более-менее работающая схема, это когда библиотеки идут на отечественном дистрибутиве.

Что делать, если тебя заблокирует отечественный дистрибутив?

А что касается этого вашего обожаемого троянского коня в виде пакетных менеджеров, то наплачитесь вы с ним еще!

Да нет, мы делаем зеркала. Поплакались ещё в 2014, когда роскомпозор заблокировал github.

hateyoufeel ★★★★★
()
Ответ на: комментарий от monk

Именно так. Поэтому для safe C нужны другие базовые типы данных (ограниченные массивы).

Ничо, когда-нибудь сишники изобретут строки с размером. Они уже почти. Ещё немножечко! Ядерщики вот уже начали, мб и до остальных дойдёт.

Но нет, для Safe C нужна более мощная система типов, а это уже будет не C. В общем-то, Frama-C и подобное – это оно и есть, накручивание сверху на сишку другую систему типизации.

hateyoufeel ★★★★★
()
Ответ на: комментарий от rtxtxtrx

Почему нельзя смириться с тем, что сишка - низкоуровневая хрень.

Потому что сишка – не низкоуровневая хрень. Сишка – весьма высокоуровневая и то же время крайне убогая хрень.

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

В сишке нет строк, нет массивов. Есть байтики и тип данных обозначающий некую область памяти где лежат 1 и более байтиков непрерывно, причем сколько их там известно лишь тебе. Если исходить из этих рассуждений, то может станет понятно, почему я как человек, который пишет на питоне встаю на защиту си, который прост как кирпич и из этой простоты выходит буст скорости. И что какие растоманы предлагают сишку как то изменить приведет к тому, что конечным юзвеням придется иметь больше оперативы и тратить больше тактов из-за инициатив фанаторастов

rtxtxtrx
()
Ответ на: комментарий от rtxtxtrx

В сишке нет строк, нет массивов.

Ну, да. Я же пишут тут: сишка – убогая хрень. К низкоуровневости это отношения не имеет. Ты ещё Brainfuck назови низкоуровневым.

который прост как кирпич и из этой простоты выходит буст скорости.

Простой сишку может назвать только дебил, не читавший стандарт и не знающий этой самой сишки. Опять же, сишка не является простой ни в каком измерении. Убогой, да, но точно не простой.

Скорость сишки – это результат тысяч человеко-лет кропотливой работы над оптимизирующими компиляторами, которые настолько насилуют код вдоль и поперёк, что предсказать по сишному коду ассемблерный выхлоп не представляет возможным даже близко. GCC и Clang/LLVM – это несколько миллионов строк код на C++ в каждом из них, и всё это нужно, чтобы сделать «простую» сишку быстрой.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 2)
Ответ на: комментарий от hateyoufeel

Да, да, просто некоторые люди слишком буквально понимают значение слова char или, например, термин машинное слово… Сейчас бы простую сишку называть сложной в сравнении с языками, где есть динамические массивы и тп. Никаких там оптимизаций: куча мусора, потому вставки на ass-sembler частенько увидишь

rtxtxtrx
()
Последнее исправление: rtxtxtrx (всего исправлений: 1)
Ответ на: комментарий от rtxtxtrx

Есть байтики и тип данных обозначающий некую область памяти где лежат 1 и более байтиков непрерывно, причем сколько их там известно лишь тебе.

Но если компилятор сможет доказать, что ты пытаешься читать или писать за пределы этой области, он может творить любую дичь.

В том-то и дело, что Си уже не переносимый ассемблер — оптимизирующий компилятор может преобразовывать код до неузнаваемости. Но система типов от ассемблера.

monk ★★★★★
()
Ответ на: комментарий от rtxtxtrx

И что какие растоманы предлагают сишку как то изменить приведет к тому, что конечным юзвеням придется иметь больше оперативы и тратить больше тактов из-за инициатив фанаторастов

Можно писать на unsafe rust и иметь скорость сишки. Но при этом всё-таки нормальную систему типов, а не указатель = строка = массив.

monk ★★★★★
()
Ответ на: комментарий от alysnix

сколько байт брать под размер?

Сколько укажет программист.

кодировка символов какая? ascii, utf8, utf16, utf32…

Которую использует исполняемая функция.

Размер нужен не для символов, а для того, чтобы strlen, sprintf и прочие могли иметь безопасную реализацию.

monk ★★★★★
()
Ответ на: комментарий от monk

Размер нужен не для символов, а для того, чтобы strlen, sprintf и прочие могли иметь безопасную реализацию.

если у вас три варианта размера и три варианта кодировки - у вас 9 вариантов функций работы со строками.

alysnix ★★★
()
Ответ на: комментарий от rtxtxtrx

Сейчас бы простую сишку называть сложной в сравнении с языками, где есть динамические массивы и тп.

Ещё раз: сишка не является простым языком. Она является убогим языком, но не простым.

hateyoufeel ★★★★★
()
Ответ на: комментарий от cumvillain

https://doc.rust-lang.org/std/primitive.str.html

Rust libraries may assume that string slices are always valid UTF-8.

то есть у русте строки - utf8. вам такие-же? с переменной длиной символа и все библиотечные строковые функции под это заточить?

alysnix ★★★
()

Тут проблема в том, что по идее код первой функции не должен компилиться, пока не добавить 'b: 'a (или наоборот, зависит от того какую версию примера использовать) в ограничения. Идея о том, что ограничения следуют из использования и теряются в процессе преобразования типов в корне ошибочна. Другой вопрос в том, что такое изменение в языке сломает огромную кучу существующего кода, при чем не факт, что все сломанное будет легко починить

q0tw4 ★★★★
()
Последнее исправление: q0tw4 (всего исправлений: 1)
Ответ на: комментарий от cumvillain

Длина строки в символах, глифах и просем это отдельная эквилибристика.

во-во! в языке системного программирования вы хотите внедрить эквилибристику с utf8,…да вас порвут! это не нужно в 99.9 процентах случаев применения.

под длину сколько байт заводить?

alysnix ★★★
()
Ответ на: комментарий от cumvillain

просто напишите либу для работы с какими хочется строками и работайте с ними.

в с++ встроенных строк тоже нет. они реализуются системной либой.

вот например. нашел в полклика.. уверен что таких либ - тонны. https://github.com/antirez/sds

alysnix ★★★
()
Последнее исправление: alysnix (всего исправлений: 1)
Ответ на: комментарий от alysnix

вот например. нашел в полклика.. уверен что таких либ - тонны.https://github.com/antirez/sds

А толку-то от них, если их никто не использует, и сишные проекты из-за просранных строк попадают в Хит Парад CVE?

hateyoufeel ★★★★★
()
Ответ на: комментарий от alysnix

ну а китайцы с клингонцами и прочими вулканцами идут на… ну да, ну да. это же инторнет тут все utf-8 даже небо и даже… я уж молчу про cp866 в котором загрузочный раздел весь. все эти интерпретаторы типа джавы используют для строк юникодовые кодировки с фиксированной длиной 3-4 байта, так и размер строки просто считать, и коллизий utf-8 можно избежать, а на вывод - да отдают utf-8

rtxtxtrx
()
Ответ на: комментарий от hateyoufeel

у тебя уже и CVE к языкам привязаны - это клиника. они не из-за «просранных» строк, а из-за ошибок в логике работы программы, ага в рантайме, ага, от которых твой говнораст с анальными запретами на выход за предела массива не спасет. у шизов переполнение стека и тп - это главные проблемы ряяяяяяяяяяяяяя. можно в стиле нынешних властей стеки запретить и тогда некого будет переполнять… самое забавное, что растоманы в реале не понимают какую наркоманию вещают

rtxtxtrx
()
Последнее исправление: rtxtxtrx (всего исправлений: 2)
Ответ на: комментарий от hateyoufeel

А толку-то от них, если их никто не использует

а вы используйте. или вы за всех переживаете?

«Золотой ты человек, Юрий Венедиктович! Не бережешь себя, всё о народе думаешь»

alysnix ★★★
()
Ответ на: комментарий от rtxtxtrx

у тебя уже и CVE к языкам привязаны - это клиника. они не из-за «просранных» строк, а из-за ошибок в логике работы программы

Да нет, 70% дыр в сишных прогах – ошибки работы с памятью: либо переполнение буфера, либо use after free. Rust решает эти две проблемы. Не понимаю, почему сишники отрицают статистику.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от rtxtxtrx

CVE к языкам привязаны - это клиника. они не из-за «просранных» строк, а из-за ошибок в логике работы программы

Ты так говоришь, будто здравая доля ошибок в логике сишной программы не приводит как раз к типичным багам работы с памятью.

unC0Rr ★★★★★
()