LINUX.ORG.RU

В Linux закрыта уязвимость ssh-keysign-pwn, позволяющая локальным пользователям читать root-файлы

 ssh-keysign-pwn, , ,


1

1

В ядре Linux исправлена уязвимость, получившая неофициальное название ssh-keysign-pwn. Проблема позволяет локальному непривилегированному пользователю читать файлы, которые должны быть доступны только root, включая приватные SSH host-ключи и, в отдельных сценариях, /etc/shadow. На момент публикации отдельный CVE для проблемы ещё не был назначен.

Несмотря на название, речь идёт не об ошибке в OpenSSH как сетевом сервере sshd, а о дефекте в логике ядра Linux, связанной с проверками ptrace и доступом к файловым дескрипторам другого процесса через pidfd_getfd(2). OpenSSH-утилита ssh-keysign оказалась одним из удобных примеров эксплуатации, потому что она работает с приватными host-ключами, которые обычно принадлежат root и недоступны обычным пользователям.

Суть ошибки в том, что функция __ptrace_may_access() некорректно обрабатывала состояние процесса, у которого уже исчезла структура памяти mm, но ещё оставались открытые файловые дескрипторы. Во время завершения процесса ядро вызывает exit_mm() раньше, чем закрывает,,, файлы через exit_files(). В этот короткий промежуток процесс уже выглядит как не имеющий обычного пользовательского адресного пространства, но его открытые файлы ещё существуют. Из-за этого проверка «dumpable»-состояния могла обходиться, а pidfd_getfd() — получить доступ к чужому файловому дескриптору при совпадающем UID.

Практический сценарий строится вокруг setuid-программ, которые сначала открывают чувствительный файл с правами root, затем сбрасывают привилегии и завершаются, всё ещё имея открытый дескриптор. В опубликованном описании в качестве примера указан ssh-keysign: он открывает /etc/ssh/ssh_host_{ecdsa,ed25519,rsa}_key, после чего сбрасывает права и может завершиться, если EnableSSHKeysign отключён. Эти ключи должны быть доступны только root, поскольку используются для host-based аутентификации.

Второй пример — chage, который может открывать /etc/shadow, затем сбрасывать эффективные права и завершаться. В результате атака не обязательно сразу даёт shell с root-правами, но позволяет получить содержимое файлов, которое обычно считается критически закрытым. Утечка /etc/shadow опасна возможностью последующего офлайн-подбора паролей, а утечка приватных SSH host-ключей — риском подмены хоста или проведения атак на доверенные SSH-сценарии.

Исправление уже принято в основную ветку Linux. Коммит 31e62c2ebbfd с заголовком ptrace: slightly saner 'get_dumpable()' logic меняет поведение проверки dumpability: ядро теперь сохраняет состояние user_dumpable при исчезновении mm и требует корректную проверку CAP_SYS_PTRACE для обхода. Патч затрагивает include/linux/sched.h, kernel/exit.c и kernel/ptrace.c.

Уязвимость была сообщена Qualys и исправлена Линусом Торвальдсом 14 мая 2026 года. Phoronix отмечает, что на момент публикации проблема затрагивала все выпуски ядра Linux вплоть до актуального состояния mainline-дерева до внесения исправления. Автор PoC также указывает, что уязвимыми являются ядра до коммита 31e62c2ebbfd, включая стабильные ветки по состоянию на 14 мая.

Отдельно важно, что для эксплуатации не требуется подгружать специфические модули ядра, как в ряде недавних LPE-уязвимостей. Достаточно локального непривилегированного доступа к системе и наличия подходящего привилегированного helper-процесса. Разработчик Debian Даниэль Бауманн отметил, что эта проблема должна устраняться обновлением ядра и последующей перезагрузкой в исправленное ядро.

В опубликованном репозитории с демонстрацией заявлена проверка на Raspberry Pi OS Bookworm с ядром 6.12.75, Debian 13, Ubuntu 22.04, Ubuntu 24.04, Ubuntu 26.04, Arch и CentOS 9. К этому списку стоит относиться как к данным автора PoC, а не как к исчерпывающему перечню: поскольку ошибка находится в общей логике ядра, фактический охват зависит от версии ядра и наличия backport-исправления у конкретного дистрибутива.

Для администраторов основная рекомендация проста: установить обновлённый пакет ядра от своего дистрибутива и перезагрузить систему. Если есть основания считать, что на машине уже был локальный непривилегированный доступ злоумышленника, после обновления стоит дополнительно рассмотреть ротацию SSH host-ключей и проверку /etc/shadow/учётных записей, поскольку сама уязвимость связана именно с чтением чувствительных файлов, а не только с абстрактным обходом проверки доступа.

В Debian уже началась работа по переносу исправления: Бауманн сообщил о cherry-pick upstream-коммита в trixie-fastforward-backports и об отправке merge request для Debian sid. В merge request прямо указано, что переносится коммит 31e62c2 для исправления ptrace-логики dumpability, позволяющей читать root-файлы непривилегированному пользователю.

>>> Источник

★★★★★

Проверено: cetjs2 ()
Последнее исправление: cetjs2 (всего исправлений: 1)

я как локальный пользователь могу не то что читать, но и править любые root-файлы без всяких уязвимостей.

amd_amd ★★★★★
()
Ответ на: комментарий от den73

Во-вторых, начинается интенсивное изменение кода, а это означает, что стабильность кода снизится

«Стабильность — это смерть или счастье?»

Стабильность при которой ошибка 12309 не исправляется десятилетиями?

macrohard ★★★
()

Серверы и рабочие станции просто обновятся, а вот Android-устройства … ну хоть рутовать станет проще.

macrohard ★★★
()
Ответ на: комментарий от den73

Я, пожалуй много болтаю

Заметно.

я всё же работаю в ИБ

Не заметно.

t500s ★★★
()
Ответ на: комментарий от den73

даже ещё не успел на этом ни миллиона заработать

Так заработай. Это же изич. Сам же пишешь. Тогда тебе и снос линукса не помеха. Зарабатываешь миллион/два/дейсять, выкупаешь физическое золото и живешь себе спокойно, пока эти старперы не опомнились.

t500s ★★★
()
Ответ на: комментарий от macrohard

Стабильность при которой ошибка 12309 не исправляется десятилетиями?

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

askh ★★★★
()
Ответ на: комментарий от wandrien

Побег через CLX — его ещё поискать в дикой природе.

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

emmawatsondtypants
()
Ответ на: комментарий от macrohard

Серверы и рабочие станции просто обновятся, а вот Android-устройства … ну хоть рутовать станет проще.

  1. Android-устройства тоже должны обновляться. Если они не обновляются, их не следует использовать, так как они уязвимы. Выбирайте вендоров – сейчас поддержка по 5-7 лет, что достаточно и даже избыточно. https://endoflife.date/android

  2. В половине случаев подобные уязвимости не работают на Android, так как там грамотно настроен SELinux, подписи на всех уровнях, по максимуму обрезаны syscall’ы, отсутствуют ненужные модули и ещё вагон всего. Android на порядок безопаснее десктопного и серверного Linux, если опираться только на базовую изоляцию прав и пользователей.

MaZy ★★★★★
()
Последнее исправление: MaZy (всего исправлений: 2)

Пока в этом вашем люнексе существует механизм setuid, он никогда не будет безопасным. Порядка 10-20% всех локальных повышений прав были вызываны setuid программами. Если в нормальных системах безопасность строится из принципа минимальных привелегий, то в setuid она строится из принципа максимальных привелегий, от которого запущенный процесс постепенно скидывает привелегии.

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

byko3y ★★★★★
()
Ответ на: комментарий от MaZy

В половине случаев подобные уязвимости не работают на Android, так как там грамотно настроен SELinux, подписи на всех уровнях, по максимуму обрезаны syscall’ы, отсутствуют ненужные модули и ещё вагон всего. Android на порядок безопаснее десктопного и серверного Linux, если опираться только на базовую изоляцию прав и пользователей.

Да, Андроид как бы показывает, что в ОС возможны права доступа, в отличие от GNU/Linux.

byko3y ★★★★★
()
Ответ на: комментарий от Infra_HDC

А логика в чём? Ну то есть, почему люди в принципе могут хотеть BSD, мне понятно. Но как такое (а не обратное) желание может возникнуть в контексте новостей о массовом закрытии дыр в Линуксе? Типа чтоб скучно не было — свалить с той ОС, где очень активно массово и целенаправленно закрывают дыры прямо сейчас на ту, где их ненайденных побольше, и находить/закрывать их если вот так массово и решат, то позже?

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 1)
Ответ на: комментарий от CrX

В BSD на просто баги и недоделки натыкаешься, а уж сколько там дыр, можно только гадать.

wandrien ★★★★
()
Ответ на: комментарий от CrX

Типа чтоб скучно не было — свалить с той ОС, где очень активно массово и целенаправленно закрывают дыры прямо сейчас на ту, где их ненайденных побольше, и находить/закрывать их если вот так массово и решат, то позже?

Нам, «не романтикам», не понять... ;)) :)))

Somebody ★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.