Десять лет критической уязвимости в Rust

Известно, что ранее АНБ США предположительно внедряло уязвимости в код открытых проектов, таких как Linux и GRUB.

Ну и желтуха

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

До этого, когда постилось от анонимуса, я удалял, потому что анонимус не может в толксы. Но от регистранта — перенёс.

Ясно

@

Понятно

Ну, спасибо, что совсем не снёс!

Это же не новость, а юбилей.

Руст страшен не своими уязвимостями. В конце концов можно создать полностью безопасный язык, надо просто запретить волюнтаризьм в преобразовании типов и адресную арифметику, и обложиться рантайм проверками.

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

какие-то боксы-шмоксы, времена жизни, счетчики ссылок, и похоже это неисправимо, поскольку убьет саму концепцию руста.

самый чистый концепт для Идеального Языка - ооп со сборкой мусора. и изоляция уровня абстракций от уровня реализации. Время жизни обьектов определяется самой динамикой, а не прописано в коде.

но НЕ ООП и БЕЗ сборки мусора, но с разметкой «времен жизни» - это какое-то максимальное удаление от идеала во мрачные глубины скорбного бытия и телесных извращений.

Прошествие того или иного периода с обнаружения уязвимости не является новостью.

Ну если юбилей - это не новость, то вот это, пожалуйста, тоже в тролксы перенеси тогда:
Языку программирования Rust исполнилось 10 лет
Фонду СПО исполнилось 39 лет
26 лет Linux.org.ru

Известно

предположительно внедряло

Тут одно или трусы или крестик.

Только не смотри вверх

самый чистый концепт для Идеального Языка - ооп со сборкой мусора.

нет никакого «идеального языка». Раст никогда не стремился заменить Джаву, а всегда был про системщину, которой сборка мусора противопоказана. Не такое большое пространство для манёвров, когда ниша языка определена. Гипотетически, Ада могла бы быть более популярной, если бы имела более компактный синтаксис а ля сишка, и тогда закрыли бы глаза на то, что она не защищает от всех проблем владения памятью. Достаточно было бы быть "чуть-чуть лучше С, но не такой монстр, как C++. Но этого не произошло, поэтому имеем то, что имеем - типа «революции» и хайп вокруг них.

мне тут zurg отвечал в комментах, что уже починили (хз, не проверял)

Языку программирования Rust исполнилось 10 лет (комментарий)

уязвимости в языке

Дальше не читал.

Апдейт от топикстартера на GutHub-е после «починили».

Update from @pnkfelix :

While the test as written above is rejected by Rust today (with the error message for line 6 saying "in type &'static &'a (), reference has a longer lifetime than the data it references"), that is just an artifact of the original source code (with its explicit type signature) running up against one new WF-check.

The fundamental issue persists, since one can today write instead:

static UNIT: &'static &'static () = &&();

fn foo<'a, 'b, T>(_: &'a &'b (), v: &'b T) -> &'a T { v }

fn bad<'a, T>(x: &'a T) -> &'static T {
    let f: fn(_, &'a T) -> &'static T = foo;
    f(UNIT, x)
}

(and this way, still get the bad behaving fn bad, by just side-stepping one of the explicit type declarations.)

Что какбе говорит на о качестве кода в конпеляторе.

Что касается zurg, то они изволили мне клоуна поставить, но по существу ничего сказать нишмагли.

Интересно, что скажут LightDiver, unC0Rr, hateyoufeel, WatchCat, FishHook и прочие достойные представители «сообщества» )))

Ну и зря!

Ввиду того, что язык - это формальная система, она либо содержит противоречия (ambigous grammar), либо неполна (soundness hole в терминологии Rust-community).

Ада могла бы быть более популярной, если бы не политика DoD и AdaCore.

Более года назад monk что-то похожее упоминал: Если вам не хватало UB в C, то вам принесли ещё (комментарий).

И вот ещё от топик-стартера: Rust is not safe!.

Ви всі брешете, такого не може бути.

ЛОЛ! Я уже и забыл, что писал об этой дыре )))

Но в любом случае, Юбилей обязывает написать о ней)))

Такая-то забота о безопасности!

Так это те же самая дыра)))

Достаточно было бы быть "чуть-чуть лучше С, но не такой монстр, как C++. Но этого не произошло

Вроде Zig позиционируется на эту роль. Но пока не особо выстрелил.

Ну вот, АНБ теперь новые бэкдоры придумывать... Неблагодарные сволочи!!

то они изволили мне клоуна поставить

Ну пардон, но больше одного за раз на лоре не поставить.

но по существу ничего сказать нишмагли.

https://godbolt.org/z/MMG3GKoh1, пять релизов уже как починено, ну в самом-то деле, несколько строчек скопипасть.

Что какбе говорит на о качестве кода в конпеляторе.

Не, это больше говорит о качестве обосёра «критики» растохейтерков, вы всё врёмя забываете снять штаны. Хотя можно было бы попинать раст за «тупой, дубовый бороучекер»(но не долго, скоро тоже на новый поменяют) или за достаточно сложную и мутную реализацию асинхронщины. Но нет, сон растохейтерского разума ничего не может родить лучше чем: «ООПе в друсте не той системы», «а ваш раст из интеренета скачан в отличие от… от… короче говно АНБшное этот ваш раст», или коронное - «а чё не как в сишке/плюсишке, хочу как в сишке, ничё не понятно, типы какие-то, взять всё да и покастить»

Посмотрел я код, а в каких случаях такое можно

1. Написать случайно

2. Написать специально и получить аппрув на пр

?

пять релизов уже как починено, ну в самом-то деле, несколько строчек скопипасть.

Если оно «пять релизов как починено», то почему у проблемы статус «Open»?

Тут может быть два ответа:

1. Проблема существует и у команды разработчиков есть пример(ы) кода, которые эксплуатируют уязвимость. И тогда возникает вопрос, где они?

2. «Оно само пофиксилось», то есть конкретно эту проблему исправлять не собирались, но так получилось, что несколько конкретных примеров кода перестали компилироваться. И тогда снова возникает вопрос, а что там с качеством кода в компиляторе?

Что скажешь?

Не, это больше говорит о качестве обосёра «критики» растохейтерков, вы всё врёмя забываете снять штаны.

Я не переходил на личности.

короче говно АНБшное

Я не утверждал, что оно говно АНБшное, но с учётом длинного послужного списка АНБ, это вполне резонное подозрение.

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

«Оно само пофиксилось», то есть конкретно эту проблему исправлять не собирались, но так получилось, что несколько конкретных примеров кода перестали компилироваться. И тогда снова возникает вопрос, а что там с качеством кода в компиляторе?

А что не так? Этот код в любом случае некорректен. Если в очередной версии добавили дополнительную проверку на ошибочность кода, то что это говорит про качество кода в компиляторе?

Вот я недавно в 1С добавлял проверку, чтобы отчёт по стажам не падал с ошибкой, если сотруднику введён суммарный стаж более 1000 лет. Значит ли это, что код, который не предполагает возможность стажа более 1000 лет, является плохим?

2. Написать специально и получить аппрув на пр

Такое вполне можно. Кода с активным использованием времён жизни достаточно много. По отдельности определения UNIT, foo и f достаточно безобидно выглядят.

Вы еще упускаете момент, что rust - не открытая система, нельзя просто взять и написать свой компилятор rust, это патентованное название. Т.е. существует один язык раст, один компилятор , один рейх. Поэтому нельзя говорить о том, что проблема в компиляторе - не проблема языка. В их инфраструктуре это неотделимые понятия.

Я все понимаю, это весело. Но почему это называется «уязвимостью»? Давайте тогда все ошибки называть уязвимостями.

«Само пофиксилось» значит, что разработчики сами не понимают, что делают.

Потому, что эта дыра в единственном «правильном» компиляторе позволяет (или позволяла???) внедрять в код на «безопасном» подмножестве Rust много всего интересного.

Например то, что позволит сформировать стекфрейм с шеллкодом…

А так как ключевого слова «unsafe» в коде не будет, то искать будут где угодно, но только не там, где оно было внедрено.

«Само пофиксилось» значит, что разработчики сами не понимают, что делают.

Да нет же. Просто добавили проверку для какого-то общего случая вывода типов. Раньше предполагали, что в этом месте проверка не нужна (на тестах не встречалась).

Из исправлений gzip 1.12 тоже делаешь вывод, что разработчики сами не понимают что делают?

А так как ключевого слова «unsafe» в коде не будет, то искать будут где угодно, но только не там, где оно было внедрено.

Поиск уязвимостей по исходникам вообще малоосмысленен. Нормальные люди (например, специалисты ФСТЭК) берут бинарник и производят поиск автоматизированными средствами.

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

А так как ключевого слова «unsafe» в коде не будет, то искать будут где угодно, но только не там, где оно было внедрено.

Вообще, unsafe делался не для защиты от злонамеренного программиста, а для помощи нормальному программисту. Чтобы уменьшить возможность случайно воткнуть UB, которое сможет использовать хакер. А злонамеренный всё равно может что-нибудь воткнуть в процесс сборки или в доступ к внешним серверам. Если бы unsafe было достаточно, то код на Java не имел бы уязвимостей совсем. Однако, пример log4j попал даже в новости.