Доступен новый выпуск утилиты sudo 1.9.17p2, используемой для организации выполнения команд от имени других пользователей. В новом выпуске устранена проблема, приводившая при определённом стечении обстоятельств к отправке сигнала SUGHUB (завершение работы) не запущенному процессу, а всем процессам в системе...Подробнее: https://www.opennet.me/opennews/art.shtml?num=63633
> без должного анализа возвращённого ранее кода ошибкиВиноват си, потому что не дает sum types. То, что разраб забыл проверить -- простительно, потому что мозг -- это мясо. Мы не можем от мяса требовать 100%-ного анализа кода. К счастью, есть язык, который автоматизирует проверки. Он бы это выявил на этапе компиляции и подсказал мясу: "тут может вернуться ошибка". Мясо бы кивнуло и поблагодарило чудо-язык за техническую помощь.
а gcc разве не выдаёт такие варнинги при компиляции?
и использование статических анализаторов разве не является обязательным при разработке критически важного софта?
Использование костылей разве не является обязательным при ходьбе?
Если вы откроете патч (https://github.com/sudo-project/sudo/commit/fb208d383af27a07...), то обнаружите, что pgrp приезжает из ec->cmnd_pid, который устанавливается вообще в другом месте, кем попало, как попало, аж в трёх си-файлах, да и там либо явно (= -1), либо очень косвенно (= cstat.val, = sudo_debug_fork()), а не из результата выполнения стандартной библиотечной функции. Компиляторный угадав тут явно бесполезен, потому что ему никто никогда не подскажет, используется ли потом это поле структуры в другом месте без проверки или просто авторы с привычками времён 80486 опять экономят байты исполняемого кода, удачно переиспользуя -1 по своему усмотрению.И, да, Result/Either type тут действительно сэкономил бы время всем, потому что компилятор бы гавкнул на попытку использовать этот тип как аргумент kill(), и сделал бы это быстро и надёжно, в отличие от статических анализаторов, которым нужно проверить миллион инвариантов среди сотен функций из десятков файлов, не запутаться в них и не вылететь по исчерпанию памяти. Если, конечно, какой-то анализатор вообще надоумили проверить, что в kill() передаётся -1 (в чём я сомневаюсь, потому что отрицательные аргументы у kill легитимны и используются гораздо чаще, чем может показаться), потому что анализировать коды возвратов тут, похоже, бесполезно (см. выше).
Они сейчас вставили проверку на -1. Ну ок, а если прилетит -2? С таким подходом ни какие расты не спасут.Их нельзя за это винить: Open Source отродясь был хобби для энтузиастов - где каждый волен галлюционировать как ему взимается. Проблему создали те, кто решил тащить создаваемый таким способом код в энтерпрайз.
> Open Source отродясь был хобби для энтузиастов - где каждый волен галлюционировать как ему взимается.Ты больной? Оупен сорс - это модель распространения исходников и не более, к качеству кода это вообще никак не относится. Или ты думаешь в закрытом софте как иначе пишут и не галлюцинируют? Достаточно венду вспомнить с её троянами, вымогателями и порнобаннерами
А где же "миллионы глаз", которые пропустили эту ошибку ещё на этапе сборки?
У семи нянек дитя с CVE
у sudo настолько огромная кодовая база что отдельному программисту практически невозможно проверить все
Переписать на Ржавом... и получится sudno.
Тогда получается, что надёжность Linux - это просто слова?
О 100% надёжности Linux никогда не говорили.
О, как! А как же "Linux работает на N компьютеров, входящих в топ-500"? Неужели обманули? 😆
Работает. А надёжность то здесь причём?
Так его пихают туда просто чтобы был?
Да уж, умственные способности вендоров поражают.. 😆
ваша аппаратная архитектура байдезинг ненадежна, о чем речь вообще.
Размер кодовой базы не причём. Налажал автор предыдущего изменения, а патч там был мелкий. В отладочном сообщении он прямо писал, что собирается вызвать killpg, но строчкой ниже вызывал kill. Если такие ошибки пропускают, значит с ревью изменений там на самом деле все плохо.
Я своими двумя посмотрел и снёс этот ваш sudo из системы. Чтобы пакеты не выпендривались, сделал псевдопакет без судо.
C не виноват в том, что люди не умеют докусентацию читать
Ниче, скоро ИИ её читать будет, новости о новом бэкдоре станут чаще здесь мелькать..
> Виноват си, потому что не дает sum typesв ядре это роскошь.
В нормальном языке типы не утекают в исполняемый код. А если именно это и надо, то пилите struct с интом в начале структуры и всеми необходимыми структурами в union ниже. Великолепно работает.
killpg - это алиас для обычной остановки постгреса
> При передаче отрицательного значения группы поведение не определенСишное мышление.
Когда привык, что UB это неотъемлемая часть системы и переносишься это на уровень пользователя.
Если я вашу rust программу (без шизофренической проверки каждого аргумента для каждой функции) запущу и на следующий день другой компонент системы, который вы в rust не контролируете (структура или код ошибки из ядра, данные из файла, из прилинкованной библиотеки), то в вашем расте внезапно тоже появится UB, потому что *ТЫ* не проверил входные данные.
Ни когда не понимал, зачем такую косую утилиту пихают почти во все дистры линукса
Потому что пользователей GUI пугают терминалы? )
Потому что он не в курсе привилегий и считает себя богом своей машинки, при этом ничего не понимая в плане безопасности надо принудительно разграничивать? )
>При передаче отрицательного значения группы поведение не определеноКосяк killpg(). Они скажут, что тот кто использует killpg() должен контролировать что передает её. Но killpg() - часть системы, и приумножать хаос своей неопределенность не должна. Тем более проверка на входе для неё не критичная в плане производительности. Это все, может быть оставлено для костылей? Но ведь поведение кода не определено при таком фактическом значение!
Описание в новости не имеет отношения к реальности, кстати. В патче не подчищают за killpg(), а меняют kill() на killpg(), а у kill() поведение при отрицательном pid как раз-таки определено чётко. Что, конечно, не отменяет ногострельности интерфейса в современных руках.
Хороши "миллионы глаз", нечего сказать. Уязвимость случайно (?) появилась в сентябре прошлого года и только сейчас заметили, что sudo неправильно обрабатывает запросы..
Ниче, ИИ все эти "случайности" найдёт.. и добавит новые..
На линуксах баг не воспроизводится. Проблему обнаружили на AIX, когда до них доехала эта версия. То что она приехала к ним через год, для энтерпрайзов это нормально.
Не «не воспроизводится», а «ещё не успели воспроизвести». Там же не только aix, но и огромная куча людей на сервере, например; давно вы такое видели на серверах? А /dev/pts у линукса тоже не резиновый, на секундочку.
Когда портируют ПО из Linux в BSD, необходимо всё проверять, т.к. многие самые обычные вещи работают по-разному. Всегда проверяю.