Уязвимости в Linux и FreeBSD, позволяющие получить root-доступ в системе

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

Эм, нет. У реализации двусвязного списка настоящая опасность только одна - его модификация во время итерирования по нему. При этом этот случай и так и так должен по-особенному обрабатываться вызывающим кодом (потому что иначе, даже если мы закостылим проблемы с памятью, будут логические ошибки), соответственно неожиданностей вроде как ждать неоткуда. В случае мультитреда добавляется ещё одно, но синхронизация тредов несколько вне зоны ответственности двусвязного списка, да и опять же скорее всего вызывающий код должен и сам как-то это учитывать в своей логике.

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

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

рантайм

Немного пооффтоплю: рантайм (runtime) - это «время выполнения программы», два смысла:

1) время, за которое выполняется программа (ну там за 1 секунду, за 5 секунд итд),

2) моменты времени, занятые её выполнением (отсюда run time error - ошибка во время выполнения, в отличие от compile time error)

Других грамотных смыслов у этого слова нет, и «заботу» оно соответственно брать не может. Некие малограмотные личности однажды идиотски сократили run time library (библиотека, необходимая во время выполнения программы) до «runtime», а затем и вовсе начали называть этим словом что попало (я в одном пхп-фреймфорке видел что рантаймом его автор назвал код парсинга аргументов командной строки), но совершенно незачем им уподобляться. Краткое сокращение для обозначения библиотек - RTL. Но надо отметить, что ни оно, ни вышеперечисленные варианты не подразумевают именно системную библиотеку.

Вон тут новость на главной про LLVM 23: добавлены функции stdc_leading_zeros_{uc,us,ui,ul,ull}. Сиди и сам матчи тип функции с типом аргумента

Не знаю зачем оно мне ненужно.

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

В Firefox часть на rust написана. Его я тоже ставлю бинарём, так как не вижу смысла компилять современные браузеры. Это бесползено. Больше ничего.

└─> equery d rust-bin
 * These packages depend on rust-bin:
dev-build/meson-1.11.1 (test-full ? dev-lang/rust-bin)
dev-python/ast-serialize-0.6.0 (>=dev-lang/rust-bin-1.93.0)
dev-python/bcrypt-5.0.0 (>=dev-lang/rust-bin-1.82.0)
dev-python/cryptography-49.0.0 (>=dev-lang/rust-bin-1.83.0)
dev-python/setuptools-rust-1.13.0 (>=dev-lang/rust-bin-1.85.0)
                                  (test ? >=dev-lang/rust-bin-1.85.0)
                                  (test ? >=dev-lang/rust-bin-1.85.0)
dev-util/maturin-1.14.1 (>=dev-lang/rust-bin-1.89.0)
dev-vcs/git-2.54.0 (rust ? >=dev-lang/rust-bin-1.74.1)
media-libs/gstreamer-1.26.11 (ptp ? >=dev-lang/rust-bin-1.74.1)
media-libs/mesa-26.1.6 (opencl ? >=dev-lang/rust-bin-1.82.0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
                       (video_cards_nvk ? >=dev-lang/rust-bin-1.82.0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
sys-devel/gcc-15.3.0 (rust ? >=dev-lang/rust-bin-1.74.1)
sys-kernel/dracut-111-r2 (dracut-cpio ? >=dev-lang/rust-bin-1.74.1)

Вот это всё зависимости от bcrypt: dev-python/ast-serialize, dev-python/cryptography, dev-python/setuptools-rust, dev-util/maturin.

В остальных пакетах rust отключён USE-флагами. Причём в профиле, т.е. мантейнерами, а не мной лично.

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

Просто ненастоящие сишники писали же, ну! А вот если бы настоящие, то ух!

его модификация во время итерирования по нему.

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

При этом этот случай и так и так должен по-особенному обрабатываться вызывающим кодом

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

синхронизация тредов несколько вне зоны ответственности двусвязного списка

Синхронизируют не треды, а доступ к списку. Имеет ли отношение сам список к доступу к нему?

У меня и на Си он не останется

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

Не знаю зачем оно мне ненужно.

Я не сомневаюсь. Повторюсь, я говорю о проблемах больших проектов с долгим временем разработки большим количеством людей. В одну морду написать прошивку, потратить на отладку полгода и почивать на лаврах можно и на си, и на асме. Эффективно писать большое и сложное - нет.

Хе. Пока тут обсуждали, у меня в фоне система обновлялась. Сейчас посмотрел, dev-python/ast-serialize из зависимостей убрали и пакет был удалён. Одной зависимостью стало меньше. :)

Включая простое хранение итераторов,

Какое ещё хранение итераторов? Итератор это переменная цикла, используется только пока цикл (итерирование) идёт. Если кто-то её пытается «хранить» - вне зависимости от последствий - это уже багоделство.

Откуда код будет знать, что сохранить итератор нельзя

Соответственно см. выше.

или что элемент таки можно удалить?

Если имеется конструкция итерирование + удаление - она всегда должна быть явно реализована как именно такая. Повторю, даже если ты закостылишь технические проблемы с указателями, тебе всё равно надо обрабатывать в вызывающем коде ситуацию «мы итерируем, дошли то такого-то элемента и он вдруг исчез». Не в плане памяти, а в плане того что тебе надо логически решить, что ты дальше будешь делать - прерывать цикл, переходить к следующему элементу, делать какие-то заглушки чтобы завершить некий протокол, итд. Возможно, удалять вообще логически нельзя и надо только пометить элемент как стоящий в очереди на удаление.

Итератор это переменная цикла

Итератор - это объект для доступа к элементам структуры данных, в данном случае списка.

Список нужен не только для того, чтобы проходить по нему в цикле.

всегда должна быть явно реализована как именно такая

всё равно надо обрабатывать в вызывающем коде

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

Ну вот, все эти «должна», «надо», «нельзя» никак не выражаются и не форсятся ЯП, а значит неизбежно кто-нибудь когда-нибудь меняя программу нечаянно допустит use-after-free, который никто не будет замечать пять лет. Возможно, даже во время прохода по списку, когда идёт сложная обработка, и где-нибудь в глубине на пять вызовов подпрограмм понадобится доступ к тому же списку, по которому идёт итерация.

По сути, спор о том, что лучше: выразить «должна», «надо», «нельзя» в коде в явном виде, или пусть будет легко написать структуру данных и так же легко её запороть.

Когда пишут большие программы, первый подход однозначно лучше.

Почти

на этом «почти» держится вся хрупкая конструкция отечественного народовластия

У тебя только два варианта эксплоитов? «Подходит для рутования говнофона» и «не существенно»?

Мне кажется, что дело не в существенности, а в статистической аномалии, которую подметил Stanson Если условно из 100 рут-эксплоитов только 20 годятся для рутования андроида - это нормально. Если из 100 имеем 0 для андроида - это уже странно и нуждается в объяснении.

Я уже дал это объяснение: Версия ядра не та, условия не те, модули не те. Для некоторых CVE нет эксплоитов, и это нормально: проблема есть, падение может быть, точный механизм триггера снаружи не ясен.

Так было всегда, но почему-то именно теперь это начало нуждаться в объяснении. Разгадка-то одна: раньше эти проблемы молча исправляли, а теперь можно верещать, что проблемы - не проблемы, а просто предлог для продвижения раста. Хотя проблемами, на самом деле, они быть не перестали.

Список нужен не только для того, чтобы проходить по нему в цикле.

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

По сути, спор о том, что лучше: выразить «должна», «надо», «нельзя» в коде в явном виде, или пусть будет легко написать структуру данных и так же легко её запороть.

Написание всего этого в коде не должно мешать программисту писать хороший код. Раст - мешает (см. пример с тем же списком).

Я уже дал это объяснение: Версия ядра не та, условия не те, модули не те

Это дефолтно годится для 80 случаев из 100, но не для 100 из 100.

Так было всегда, но почему-то именно теперь это начало нуждаться в объяснении.

Выше ответили. Все эти факторы (версия ядра не та, условия не те, модули не те) они, по идее, влияют на все виды систем. Но непонятно, почему андроид на фоне этих факторов оказывается особо защищенным?

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

Выше ответили.

Это всё вилами по воде писано.

CVE назначается по факту потенциальной возможности, а не наличию эксплоита. Прямо в новости указано наличие эксплоитов для двух уязвимостей. За последние три месяца было еще как минимум два эксплоита, позволяющих простым запуском бинаря повысить свои привелегии.

То, что они не подходят для андроида - не отменяет их существования. То, что остальные уязвимости не имеют эксплоитов - совершенно типично для CVE.

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

Мне кажется, это так себе подход к проблеме.

время жизни итератора жёстко ограничено и утекать он никуда не должен ни для каких целей.

Кто сказал? Зачем, почему? В расте никаких проблем передать итератор куда-нибудь нет.

Написание всего этого в коде не должно мешать программисту писать хороший код. Раст - мешает

Во-первых, только по твоему мнению, а по моему нет. Возможно, само понятие хорошего кода нужно переосмыслить.

Во-вторых, в чём логика, встретившись с небольшим неудобством написания «хорошего» кода, кидаться в лёгкое написание говна? Просто потому что нравится лёгкость?

Кто сказал?

Я.

Зачем, почему?

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

В расте никаких проблем передать итератор куда-нибудь нет.

Передать в рамках времени его жизни (т.е. в функцию, которую ты вызвал из цикла и которая никуда его не сохранит) - норм. Передать куда-то налево - не норм, если он это разрешает значит он плохой.

никуда его не сохранит

А она и не сохранит. Она вызовет другую функцию, та третью, а в четвёртой будет условие, при котором список полностью очищается. Удачи.

Ладно, отслеживание подобных случаев возможно и правда полезно, но раст это делает, заодно мешая писать нормальные штуки, это не дело. А не мешая такую штуку и не заблокировать, т.к. компилятор не может во время компиляции трассировать все пути выполнения программы чтобы определить, может ли что-то случиться или нет. А запрещать вызов какой-то функции просто потому, что в ней есть строка, чистящая список (неизвестно, дойдёт ли до неё исполнение или нет) - не надо.

Всего за август раскрыта информация о 1668 уязвимостях в ядре Linux.

Также во FreeBSD устранено 8 уязвимостей,

Круто! 1668 и 8…