10-летний баг sudo, позволяющий получить root-права, наконец пофиксили

10-летний баг sudo, позволяющий получить root-права, наконец пофиксили

10-летний баг sudo, позволяющий получить root-права, наконец пофиксили

Исследователи из компании Qualys сообщили о критической уязвимости переполнения буфера в sudo, которую злоумышленники могут использовать для получения контроля над Linux-хостом. Разработчики уже выпустили соответствующий патч, пользователям остаётся только установить его.

Программа sudo используется для администрирования UNIX-систем. С её помощью можно наделить того или иного пользователя повышенными правами или выполнить команды от имени root и других юзеров.

Баг, который нашли специалисты Qualys, получил идентификатор CVE-2021-3156. Его опасность заключается в том, что любой локальный пользователь может получить root-доступ на уязвимом хосте с конфигурацией по умолчанию.

Qualys решила раскрыть информацию об уязвимости, согласовав изначально это с разработчиками операционных систем. По словам исследователей, затронуты следующие версии sudo: с 1.8.2 по 1.8.31p2, с 1.9.0 по 1.9.5p1.

Эксперты Qualys даже написали несколько эксплойтов для отдельных дистрибутивов: Ubuntu 20.04 (sudo 1.8.31), Debian 10 (sudo 1.8.27) и Fedora 33 (sudo 1.9.2). Другие дистрибутивы также затронуты брешью, считают специалисты. К слову, разработчики Ubuntu и Red Hat уже опубликовали соответствующие патчи.

«"set_cmnd()" уязвима к переполнению буфера, поскольку находящиеся за границами символы, копируемые в буфер "user_args", не включаются в размер», — отмечается в отчёте (TXT) Qualys.

Также эксперты объяснили, что им удалось обойти защитный механизм ASLR, который предназначен для нейтрализации подобных эксплойтов. Самое интересное, что впервые об этом баге стало известно в июле 2011 года, однако его устранили лишь сейчас.

GitHub сделает платными собственные раннеры для Actions

GitHub меняет подход к оплате Actions и готовится брать деньги за то, что раньше было бесплатным. С марта компания начнёт взимать плату за использование собственных раннеров в приватных репозиториях — по $0,002 за минуту работы. Для публичных репозиториев ничего не меняется: там собственные раннеры по-прежнему бесплатны.

Об изменениях GitHub сообщил в блоге, одновременно анонсировав снижение цен на GitHub-раннеры с 1 января. Всё это компания объединяет под лозунгом «более простое ценообразование и лучший опыт работы с GitHub Actions».

Реакция крупных пользователей оказалась ожидаемой. В DevOps-сообществе новость встретили без энтузиазма. Один из пользователей Reddit рассказал, что для его команды новые тарифы означают плюс около $3,5 тыс. в месяц к счёту GitHub — и это при использовании собственных серверов.

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

При этом GitHub уверяет, что большинство пользователей изменений не почувствует. По оценке компании:

  • 96% клиентов не увидят роста расходов вообще;
  • из оставшихся 4% у 85% затраты даже снизятся;
  • для оставшихся 15% медианный рост составит около $13 в месяц.

Для тех, кто использует самохостные раннеры и хочет заранее понять, во что это выльется, GitHub обновил калькулятор цен, добавив туда новые расчёты.

Тем не менее для крупных команд и корпоративных проектов нововведение может стать поводом пересмотреть CI/CD-процессы — особенно если их раннеры использовались активно именно ради экономии.

RSS: Новости на портале Anti-Malware.ru