Доступен новый выпуск утилиты sudo 1.9.17p2, используемой для организации выполнения команд от имени других пользователей. В новом выпуске устранена проблема, приводившая при определённом стечении обстоятельств к отправке сигнала SUGHUB (завершение работы) не запущенному процессу, а всем процессам в системе...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63633

• Обновление sudo 1.9.17p2 с устранением ошибки, отправлявшей ...,Аноним, 08:07 , 27-Июл-25
  • Обновление sudo 1.9.17p2 с устранением ошибки, отправлявшей ...,onanim, 08:55 , 27-Июл-25
    • Обновление sudo 1.9.17p2 с устранением ошибки, отправлявшей ...,Аноним, 10:01 , 27-Июл-25
    • Обновление sudo 1.9.17p2 с устранением ошибки, отправлявшей ...,вымя, 10:24 , 27-Июл-25
      • Обновление sudo 1.9.17p2 с устранением ошибки, отправлявшей ...,1, 17:10 , 27-Июл-25
  • Обновление sudo 1.9.17p2 с устранением ошибки, отправлявшей ...,Anonimm, 09:34 , 27-Июл-25
    • Обновление sudo 1.9.17p2 с устранением ошибки, отправлявшей ...,нейм, 10:28 , 27-Июл-25
    • Обновление sudo 1.9.17p2 с устранением ошибки, отправлявшей ...,Аноним, 11:57 , 27-Июл-25
      • Обновление sudo 1.9.17p2 с устранением ошибки, отправлявшей ...,Аноним, 12:17 , 27-Июл-25
      • Обновление sudo 1.9.17p2 с устранением ошибки, отправлявшей ...,Anonimm, 13:29 , 27-Июл-25
        • Обновление sudo 1.9.17p2 с устранением ошибки, отправлявшей ...,Аноним, 15:14 , 27-Июл-25
          • Обновление sudo 1.9.17p2 с устранением ошибки, отправлявшей ...,Anonimm, 15:57 , 27-Июл-25
            • Обновление sudo 1.9.17p2 с устранением ошибки, отправлявшей ...,Нононим, 16:01 , 27-Июл-25
              • Обновление sudo 1.9.17p2 с устранением ошибки, отправлявшей ...,Anonimm, 16:05 , 27-Июл-25
        • Обновление sudo 1.9.17p2 с устранением ошибки, отправлявшей ...,Аноним, 15:56 , 27-Июл-25
      • Обновление sudo 1.9.17p2 с устранением ошибки, отправлявшей ...,1, 16:43 , 27-Июл-25
  • Обновление sudo 1.9.17p2 с устранением ошибки, отправлявшей ...,Аноним, 13:52 , 27-Июл-25
    • Обновление sudo 1.9.17p2 с устранением ошибки, отправлявшей ...,Anonimm, 15:59 , 27-Июл-25
  • Обновление sudo 1.9.17p2 с устранением ошибки, отправлявшей ...,Аноним, 15:01 , 27-Июл-25
• Обновление sudo 1.9.17p2 с устранением ошибки, отправлявшей ...,Аноним, 09:17 , 27-Июл-25
• Обновление sudo 1.9.17p2 с устранением ошибки, отправлявшей ...,Карлос Сношайтилис, 12:31 , 27-Июл-25
• Обновление sudo 1.9.17p2 с устранением ошибки, отправлявшей ...,Аноним, 13:55 , 27-Июл-25
  • Обновление sudo 1.9.17p2 с устранением ошибки, отправлявшей ...,Аноним, 14:58 , 27-Июл-25
• Обновление sudo 1.9.17p2 с устранением ошибки, отправлявшей ...,Аноним, 14:52 , 27-Июл-25
  • Обновление sudo 1.9.17p2 с устранением ошибки, отправлявшей ...,вымя, 15:33 , 27-Июл-25
• Обновление sudo 1.9.17p2 с устранением ошибки, отправлявшей ...,Anonimm, 16:03 , 27-Июл-25
  • Обновление sudo 1.9.17p2 с устранением ошибки, отправлявшей ...,1, 16:52 , 27-Июл-25

> без должного анализа возвращённого ранее кода ошибки

Виноват си, потому что не дает 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 отродясь был хобби для энтузиастов - где каждый волен галлюционировать как ему взимается. Проблему создали те, кто решил тащить создаваемый таким способом код в энтерпрайз.

А где же "миллионы глаз", которые пропустили эту ошибку ещё на этапе сборки?

У семи нянек дитя с CVE

у sudo настолько огромная кодовая база что отдельному программисту практически невозможно проверить все

Переписать на Ржавом... и получится sudno.

Тогда получается, что надёжность Linux - это просто слова?

О 100% надёжности Linux никогда не говорили.

О, как! А как же "Linux работает на N компьютеров, входящих в топ-500"? Неужели обманули? 😆

Работает. А надёжность то здесь причём?

Так его пихают туда просто чтобы был?
Да уж, умственные способности вендоров поражают.. 😆

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

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

C не виноват в том, что люди не умеют докусентацию читать

Ниче, скоро ИИ её читать будет, новости о новом бэкдоре станут чаще здесь мелькать..

> Виноват си, потому что не дает sum types

в ядре это роскошь.

killpg - это алиас для обычной остановки постгреса

> При передаче отрицательного значения группы поведение не определен

Сишное мышление.

Когда привык, что UB это неотъемлемая часть системы и переносишься это на уровень пользователя.

Ни когда не понимал, зачем такую косую утилиту пихают почти во все дистры линукса

Потому что пользователей GUI пугают терминалы? )
Потому что он не в курсе привилегий и считает себя богом своей машинки, при этом ничего не понимая в плане безопасности надо принудительно разграничивать? )

>При передаче отрицательного значения группы поведение не определено

Косяк killpg(). Они скажут, что тот кто использует killpg() должен контролировать что передает её. Но killpg() - часть системы, и приумножать хаос своей неопределенность не должна. Тем более проверка на входе для неё не критичная в плане производительности. Это все, может быть оставлено для костылей? Но ведь поведение кода не определено при таком фактическом значение!  

Описание в новости не имеет отношения к реальности, кстати. В патче не подчищают за killpg(), а меняют kill() на killpg(), а у kill() поведение при отрицательном pid как раз-таки определено чётко. Что, конечно, не отменяет ногострельности интерфейса в современных руках.

Хороши "миллионы глаз", нечего сказать. Уязвимость случайно (?) появилась в сентябре прошлого года и только сейчас заметили, что sudo неправильно обрабатывает запросы..
Ниче, ИИ все эти "случайности" найдёт.. и добавит новые..

На линуксах баг не воспроизводится. Проблему обнаружили на AIX, когда до них доехала эта версия. То что она приехала к ним через год, для энтерпрайзов это нормально.