В безопасности Debian и ряда других дистрибутивов Linux обнаружилась огромная брешь, которая оставалась незамеченной с версии 2.6. Все интернет-издания ссылаются на отчет авторства Гектора Марко и Исмаила Риполла из компании Cybersecurity Group.
Уязвимость находится в скриптах, которые дают доступ к разбивке системы на разделы, при условии, что процедура защищена с помощью Linux Unified Key Setup (LUKS). Сведения о «слабом месте» были обнародованы 11 ноября во время конференции по безопасности DeepSec 2016 в Вене. Название доклада, прозвучавшего со сцены, — «Злоупотребление LUKS для взлома системы».
Спать с открытой входной дверью
Уязвимость в системе дает доступ к оболочке корневых файлов initramfs. Проблема стабильна и не зависит от особенностей системы или конфигурации. Взломщики могут скопировать, внести изменения или разрушить жесткий диск и еще настроить сеть на неавторизованную передачу данных.
Чтобы активировать уязвимость, надо загрузить систему, нажать «Enter», подержать и подождать около полутора минут. После этого система приведет вас в корневую оболочку BusyBox. Эту проблему в первую очередь нужно решать в системах библиотек, банкоматах, аэропортах — везде, где весь процесс загрузки защищен всего лишь паролем в BIOS, а из устройств ввода есть мышка, клавиатура. Уязвимы могут быть и облачные окружения без физического доступа.
Какие системы подвержены уязвимости
Debian и Ubuntu с зашифрованными системными разделами — скорее всего, все дистрибутивы, но авторы отчета это не проверяли. Также все системы с Dracut вместо initramfs — это Fedora, Red Hat Enterpise Linux, и SUSE Linux Enterprise Server.
Защита разделения дискового пространства
Происходит во время инсталляции системы, когда предлагается поделить диск, если есть необходимость, и отформатировать его части. После этого пользователь может выбрать опцию шифрования из соображений безопасности.
Пример
Ниже показано, как выглядит классическая структура уязвимой системы, защищенной всего одним паролем.
Видно, что
/dev/sda5 зашифровано и использовано как физический диск в группе lubuntu-vg, которая состоит из двух логических дисков lubuntu--vg-root и lubuntu--vg-swap_1.Чем чревато
С доступом к консоли и опцией перезагрузки системы хакер способен запустить оболочку без корневых разрешений в окружении initrd. Пароль разблокирует системный раздел. Если один раздел запаролен, это не значит, что и остальные тоже защищены. Злоумышленник может многое: от расширения прав локального пользователя до полного удаления всей информации на диске.
Как так получилось
Брешь образовалась в некорректной процедуре обработки проверки пароля. После трех неудачных попыток система позволяет пробовать еще и еще.
Корень ошибки скрывается в файле
/scripts/local-top/cryptroot. Как только вы превысили максимальное количество попыток обвала переходных аппаратных средств, вы получаете права доступа к корневому уровню.Таблетка от невнимательности
Остановите последовательность загрузки, когда количество попыток введения пароля заканчивается. Этот патч откладывает выполнение навсегда. Чтобы выйти — перезагрузите компьютер.
Что делать
Разработчики дистрибутивов выпустят фикс проблемы, но заботливым администраторам ждать не стоит — пропатчите систему сами.
В комментариях к посту пользователь demfloro указал на возможный обход проблемы до исправления: нужно добавить параметр
panic к строке загрузки. Подробнее можно посмотреть у авторов отчета в разделе «Workaround».Комментарии (32)
merlin-vrn
16.11.2016 14:23+3Автор, переименуйте в "Уязвимость скриптов инициализации Cryptsetup в Debian". Про уязвимости cryptsetup в linux ни одной буквы нет. Cryptsetup вообще нет в Linux, это утилита окружения, взаимодействующая с ядром, а не часть ядра. А интерфейс ядра — dm-crypt — не пользовательский и Enter к нему никакого отношения не имеет.
martin74ua
16.11.2016 14:33+1Сказочники.
Не поверил, взял виртуалку, дистрибутив Centos 6.8, поставил, при установке выбрал «зашифровать систему». После старта и загрузки ядра запросили пароль. Ничего не вводил, прилег подремать на Enter. Ожидаемо добился сообщения Wrong password и кернел паника (радостно начали мигать индикаторы caps, num, scrool).
ресетнул виртуалку. В параметрах ядра отключил rhgb quiet, получил лог загрузки системы. Эффект тот же.
Авторы, куда и как мне нужно нажать, чтобы я получил шелл? Про init=/bin/sh в параметры ядра я в курсе. Попробовал. Все равно просят пароль на sda2, и пока не введу — ничего не дают. Через полторы минуты я получаю kernel panic. Как в таком состоянии добраться до системы — честно не знаю, не разработчик. Но по моему кроме как reset ничего и сделать то нельзя…
Так что не верю. Если в конкретном дистрибутиве ошибка в инит скриптах, которая позволяет не монтировать систему и получить шелл — так это проблема этого дистрибутива.
quzor
16.11.2016 14:54-1В любом ПО могут быть ошибки. А вот, что вы пытались доказать этим комментарием — непонятно.
martin74ua
16.11.2016 15:07+4Я проверил утверждение насчет систем с dracut. Нету тут такого. 5 раз неверно ввел пароль — kernel panic. Никаких шеллов.
Для проверки поставил убунту сервер 16.04. Да, действительно, если зажать ентер — вываливаемся в шелл busybox.
Проблема исключительно в дебианах и убунтах. Правда чистый дебиан я не проверял, желающие могут проверить сами.merlin-vrn
16.11.2016 15:41+1Есть там такая проблема. Я эти скрипты инициализации курил, но насчёт именно своего сценария использования (вообще такое должен делать каждый, кто внедряет такого рода безопасность). В моём случае данная "уязвимость" не является сколь-нибудь важной проблемой.
Да и вообще, эта уязвимость становится проблемой в случае, когда на компьютере с диском нельзя запустить своё ПО, т.е.: система загрузки — заблокирована (TPM, встроенная защита UEFI и так далее), а вынуть диск и подключить к своему компьютеру нельзя.
Если я, скажем, на компе могу стартовать свою систему с флешки и смонтировать загрузочный раздел, меня вообще не волнует, какая там безопасность в инитрамфс и ядре — подсунуть кейлоггер я завсегда смогу.martin74ua
16.11.2016 15:45Целиком с вами согласен. Если у меня есть физический доступ к серверу — то защититься от меня практически невозможно ;)
past
16.11.2016 14:48+2Вот более корректное описание уязвимости с ЛОРа
Найденная уязвимость позволяет получить доступ к оболочке busybox с привилегиями администратора, если удерживать клавишу ввода около 70 секунд во время запроса пароля к зашифрованному тому.
Это неприятно для систем с ограниченным локальным доступом. Атакующий может, например, установить кейлоггер или скачать зашифрованный раздел на внешнюю систему для последующего анализа.
С большой вероятностью, уязвимы все системы, использующие cryptsetup, в первую очередь, основывающиеся на Debian.
yaka
16.11.2016 14:55+2То есть, если выбросить всю желтизну из статьи, то проблема только в конкретных скриптах в нескольких дистрибутивах (Ubuntu, Debian и их потомки).
Пользователи самосборных initramfs спят спокойно, ручные пользователи cryptsetup спят спокойно. Что с genkernel?
Erelecano
16.11.2016 15:07Linux — ядро с использованием которого создают разные ОС. Бывает Debian GNU/Linux, бывает Android Linux, бывает OpenWRT Linux, бывает Ubuntu Linux и Red Hat Enterprise Linux. Уязвимости в Linux нет. Вами описана уязвимость в стартовых скриптах конкретных дистрибутивов.
И, да, ядро не может выпустить обновления, оно пока еще не развилось до искусственного интеллекта.
martin74ua
16.11.2016 15:12+1>Уязвимы могут быть и облачные окружения без физического доступа
Объясните пожалуйста вот это предложение.
Если у меня есть доступ к консоли виртуального сервера — это абсолютно равнозначно физическому доступу к физическому серверу. Даже если некий хакер доведет виртуалку до ребута — как он сможет воспользоваться этой проблемой? Как ему «нажать enter на 70 сек при запросе пароля от зашифрованного тома»?
blind_oracle
16.11.2016 15:38Где тут уязвимость я никак в толк не возьму.
Если я в GRUB добавлю init=/bin/sh (или что там в initramfs есть), то попаду ровно туда же.
Зашифрованные разделы так и останутся зашифрованными.martin74ua
16.11.2016 15:40А вы добавьте ;) Я специально на centos попробовал — пока не введешь пароль от криптованного раздела — шелла не будет.
merlin-vrn
16.11.2016 15:46Нет, если корневой раздел зашифрован, вы получите панику. Да и груб не должен дать возможность редактировать строку ядра.
Представьте: комп разобрать не удаётся, выбор устройства загрузки залочен в UEFI (т.е. тыкай, не тыкай флешки — нет пути), но можно подержать Enter и получить шелл, с помощью которого в initramfs, хранящийся на незашифрованном разделе, можно встроить кейлоггер.
blind_oracle
16.11.2016 16:19Это какая-то очень специфичная ситуация, на мой взгляд.
Да и пересобрать initramfs изнутри него я думаю никак не удастся, только заменить если есть доступ по сети какой-либо, что учитывая ограниченность initramfs — вряд-ли.
В общем, не думаю что в реальности это какой-либо значимый security flaw.
blind_oracle
16.11.2016 16:22Да и груб не должен дать возможность редактировать строку ядра.
По дефолту — всё доступно без проблем.
al_one
16.11.2016 15:51+6This vulnerability allows to obtain a root initramfs shell on affected systems.
Уязвимость в системе дает доступ к оболочке корневых файлов initramfs.
An attacker with access to the console of the computer and with the ability to reboot the computer can launch a shell (with root permissions) when he/she is prompted for the password to unlock the system partition.
С доступом к консоли и опцией перезагрузки системы хакер способен запустить оболочку без корневых разрешений в окружении initrd.
Несколько абзацев оригинальной статьи, в которых описывается самая суть, причина ошибки, переведены как:
Как только вы превысили максимальное количество попыток обвала переходных аппаратных средств, вы получаете права доступа к корневому уровню.
PROMT? Magic Gooddy? Надмозг? Редактор Хабра? Почему не помечено как перевод?
#Make Habr tort again!
Shapelez
16.11.2016 16:12У меня один простой вопрос — почему вы сами тогда, «правильно и грамотно», не написали об этом? Очень легко критиковать публикации авторов, но у вас я не вижу ни одной таковой. Понимаете?
al_one
16.11.2016 16:56+2Аргумент «сперва добейся»?
Ответ прост: я не умею писать, поэтому не пишу. Но читать-то я умею.
Вы сами как оцениваете качество этого перевода?Shapelez
16.11.2016 17:03+1Оцениваю выше ваших оскорблений. Разве я где-то написал что-то подобное тому, в чём вы пытаетесь меня упрекнуть? Нет.
Мой принцип простой: «Критикуешь — Предлагай, Предлагаешь — Делай». У вас только критика, исправлений автору вы не предложили, а ведь с этого стоило начать.
И ещё — если вы умный, стоит учить окружающих людей, делая таким образом лучше всем. Надменно упрекая вы лишь ускоряете общее движение в обратном направлении.al_one
16.11.2016 17:36+1Здравствуйте. Ну а что я могу предложить? К сожалению, Анастасия, похоже, не очень хорошо разбирается в теме статьи. Здесь чуть ли не каждый абзац надо переписывать. Мне почему-то не хочется выполнять за другого человека его (вероятно, оплачиваемую) работу.
Это в частности. А в общем у меня стандартное нытьё про слишком уж большое количество редакторских статей, на фоне которых приходится отыскивать крупицы от специалистов.Shapelez
16.11.2016 18:07+1Ну, вот так и получается, что, так как специалисты не считают нужным писать самостоятельно об интересных темах, приходится Анастасии (которая девушка далеко не глупая) вникать вот в такие вот вещи. Но, главное, это что Анастасия открыта к диалогу и вполне способна реагировать на нормальные замечания. Я понимаю, что вы, субъективно, всё бы переписали — я бы тоже написал иначе, но суть в том, что сделала это Анастасия, а не мы с вами.
al_one
16.11.2016 18:54+1Может быть прозвучит грубо и даже невежливо, т.к. говорим в третьем лице, но зачем Анастасия пишет о том, что ей не интересно? Ведь поленилась же хотя бы в Википедии почитать что такое Root. Здесь уже и в комментариях куча вопросов, которые по понятным причинам останутся без ответа от автора.
Выглядит так, как будто я нападаю на неё лично, но нет. Понятно, что девушка она не глупая, и вообще разбирается в вещах, хоть эта статья и переведена «на отстань».
Что меня больше удручает, так это большое количество таких статей, когда автор пишет не потому что хочет, а потому что надо «гнать контент».Shapelez
16.11.2016 20:31+1Вы правда считаете, что в данном конкретном случае уместно словосочетание «гнать контент»? Вроде, о важной вещи сообщили, интересной многим причастным. Да, были ошибки — их исправили. Всё-равно дать ответы на все вопросы в рамках одной публикации почти всегда невозможно. Между прочим, вы снова додумали — никто не говорил о том, что Анастасии эта тема не интересна :)
al_one
16.11.2016 23:41-1Да, считаю словосочетание абсолютно уместным. И не только в этом случае, а и ко многим статьям редакторов.
Ошибки не исправили. Как перевод не пометили.
Да, вещь важная, но на профильных ресурсах новость уже проходила, так что большинство уже в курсе. Заметка на OpenNet, например, на голову лучше, чем здесь. (Заодно посмотрите как переводятся встречающиеся в тексте термины).
esudnik
16.11.2016 19:53Очень удивительно что такую уязвимость только сейчас заметили.
merlin-vrn
16.11.2016 21:41Она не такая уж и страшная. И в большом количестве инсталляций, подозреваю, не этот конкретный момент лимитирует общую защищённость системы.
Acid_Jack
16.11.2016 21:28Хотел испугаться и не успел. Сижу на тестинге, а там эту ошибку исправили ещё 7-го ноября:
http://metadata.ftp-master.debian.org/changelogs/main/c/cryptsetup/cryptsetup_1.7.3-2_changelog
Теперь после трёх неудачных попыток ввода пароля консоль блокируется на 1 минуту (по умолчанию).
xforce
Кто такой Linux и куда он выпустит фикс проблемы? Не говоря уж о том, что уязвимость в скриптах инициализации, а «минимуальную уязвимую версию» приводят по версии ядра. Ядро не содержит в себе скрипты инициализации и не содержит этой уязвимости, если я правильно понял прочитанное.