Comments 32
Кто такой Linux и куда он выпустит фикс проблемы? Не говоря уж о том, что уязвимость в скриптах инициализации, а «минимуальную уязвимую версию» приводят по версии ядра. Ядро не содержит в себе скрипты инициализации и не содержит этой уязвимости, если я правильно понял прочитанное.
Автор, переименуйте в "Уязвимость скриптов инициализации Cryptsetup в Debian". Про уязвимости cryptsetup в linux ни одной буквы нет. Cryptsetup вообще нет в Linux, это утилита окружения, взаимодействующая с ядром, а не часть ядра. А интерфейс ядра — dm-crypt — не пользовательский и Enter к нему никакого отношения не имеет.
Сказочники.
Не поверил, взял виртуалку, дистрибутив Centos 6.8, поставил, при установке выбрал «зашифровать систему». После старта и загрузки ядра запросили пароль. Ничего не вводил, прилег подремать на Enter. Ожидаемо добился сообщения Wrong password и кернел паника (радостно начали мигать индикаторы caps, num, scrool).
ресетнул виртуалку. В параметрах ядра отключил rhgb quiet, получил лог загрузки системы. Эффект тот же.
Авторы, куда и как мне нужно нажать, чтобы я получил шелл? Про init=/bin/sh в параметры ядра я в курсе. Попробовал. Все равно просят пароль на sda2, и пока не введу — ничего не дают. Через полторы минуты я получаю kernel panic. Как в таком состоянии добраться до системы — честно не знаю, не разработчик. Но по моему кроме как reset ничего и сделать то нельзя…
Так что не верю. Если в конкретном дистрибутиве ошибка в инит скриптах, которая позволяет не монтировать систему и получить шелл — так это проблема этого дистрибутива.
Не поверил, взял виртуалку, дистрибутив Centos 6.8, поставил, при установке выбрал «зашифровать систему». После старта и загрузки ядра запросили пароль. Ничего не вводил, прилег подремать на Enter. Ожидаемо добился сообщения Wrong password и кернел паника (радостно начали мигать индикаторы caps, num, scrool).
ресетнул виртуалку. В параметрах ядра отключил rhgb quiet, получил лог загрузки системы. Эффект тот же.
Авторы, куда и как мне нужно нажать, чтобы я получил шелл? Про init=/bin/sh в параметры ядра я в курсе. Попробовал. Все равно просят пароль на sda2, и пока не введу — ничего не дают. Через полторы минуты я получаю kernel panic. Как в таком состоянии добраться до системы — честно не знаю, не разработчик. Но по моему кроме как reset ничего и сделать то нельзя…
Так что не верю. Если в конкретном дистрибутиве ошибка в инит скриптах, которая позволяет не монтировать систему и получить шелл — так это проблема этого дистрибутива.
В любом ПО могут быть ошибки. А вот, что вы пытались доказать этим комментарием — непонятно.
Я проверил утверждение насчет систем с dracut. Нету тут такого. 5 раз неверно ввел пароль — kernel panic. Никаких шеллов.
Для проверки поставил убунту сервер 16.04. Да, действительно, если зажать ентер — вываливаемся в шелл busybox.
Проблема исключительно в дебианах и убунтах. Правда чистый дебиан я не проверял, желающие могут проверить сами.
Для проверки поставил убунту сервер 16.04. Да, действительно, если зажать ентер — вываливаемся в шелл busybox.
Проблема исключительно в дебианах и убунтах. Правда чистый дебиан я не проверял, желающие могут проверить сами.
Есть там такая проблема. Я эти скрипты инициализации курил, но насчёт именно своего сценария использования (вообще такое должен делать каждый, кто внедряет такого рода безопасность). В моём случае данная "уязвимость" не является сколь-нибудь важной проблемой.
Да и вообще, эта уязвимость становится проблемой в случае, когда на компьютере с диском нельзя запустить своё ПО, т.е.: система загрузки — заблокирована (TPM, встроенная защита UEFI и так далее), а вынуть диск и подключить к своему компьютеру нельзя.
Если я, скажем, на компе могу стартовать свою систему с флешки и смонтировать загрузочный раздел, меня вообще не волнует, какая там безопасность в инитрамфс и ядре — подсунуть кейлоггер я завсегда смогу.
Вот более корректное описание уязвимости с ЛОРа
Найденная уязвимость позволяет получить доступ к оболочке busybox с привилегиями администратора, если удерживать клавишу ввода около 70 секунд во время запроса пароля к зашифрованному тому.
Это неприятно для систем с ограниченным локальным доступом. Атакующий может, например, установить кейлоггер или скачать зашифрованный раздел на внешнюю систему для последующего анализа.
С большой вероятностью, уязвимы все системы, использующие cryptsetup, в первую очередь, основывающиеся на Debian.
В оригинале также упоминается обход проблемы до исправления (workaround): добавить параметр panic к строке загрузки.
То есть, если выбросить всю желтизну из статьи, то проблема только в конкретных скриптах в нескольких дистрибутивах (Ubuntu, Debian и их потомки).
Пользователи самосборных initramfs спят спокойно, ручные пользователи cryptsetup спят спокойно. Что с genkernel?
Пользователи самосборных initramfs спят спокойно, ручные пользователи cryptsetup спят спокойно. Что с genkernel?
Linux — ядро с использованием которого создают разные ОС. Бывает Debian GNU/Linux, бывает Android Linux, бывает OpenWRT Linux, бывает Ubuntu Linux и Red Hat Enterprise Linux. Уязвимости в Linux нет. Вами описана уязвимость в стартовых скриптах конкретных дистрибутивов.
И, да, ядро не может выпустить обновления, оно пока еще не развилось до искусственного интеллекта.
И, да, ядро не может выпустить обновления, оно пока еще не развилось до искусственного интеллекта.
>Уязвимы могут быть и облачные окружения без физического доступа
Объясните пожалуйста вот это предложение.
Если у меня есть доступ к консоли виртуального сервера — это абсолютно равнозначно физическому доступу к физическому серверу. Даже если некий хакер доведет виртуалку до ребута — как он сможет воспользоваться этой проблемой? Как ему «нажать enter на 70 сек при запросе пароля от зашифрованного тома»?
Объясните пожалуйста вот это предложение.
Если у меня есть доступ к консоли виртуального сервера — это абсолютно равнозначно физическому доступу к физическому серверу. Даже если некий хакер доведет виртуалку до ребута — как он сможет воспользоваться этой проблемой? Как ему «нажать enter на 70 сек при запросе пароля от зашифрованного тома»?
Где тут уязвимость я никак в толк не возьму.
Если я в GRUB добавлю init=/bin/sh (или что там в initramfs есть), то попаду ровно туда же.
Зашифрованные разделы так и останутся зашифрованными.
Если я в GRUB добавлю init=/bin/sh (или что там в initramfs есть), то попаду ровно туда же.
Зашифрованные разделы так и останутся зашифрованными.
А вы добавьте ;) Я специально на centos попробовал — пока не введешь пароль от криптованного раздела — шелла не будет.
Нет, если корневой раздел зашифрован, вы получите панику. Да и груб не должен дать возможность редактировать строку ядра.
Представьте: комп разобрать не удаётся, выбор устройства загрузки залочен в UEFI (т.е. тыкай, не тыкай флешки — нет пути), но можно подержать Enter и получить шелл, с помощью которого в initramfs, хранящийся на незашифрованном разделе, можно встроить кейлоггер.
Это какая-то очень специфичная ситуация, на мой взгляд.
Да и пересобрать initramfs изнутри него я думаю никак не удастся, только заменить если есть доступ по сети какой-либо, что учитывая ограниченность initramfs — вряд-ли.
В общем, не думаю что в реальности это какой-либо значимый security flaw.
Да и пересобрать initramfs изнутри него я думаю никак не удастся, только заменить если есть доступ по сети какой-либо, что учитывая ограниченность initramfs — вряд-ли.
В общем, не думаю что в реальности это какой-либо значимый security flaw.
Да и груб не должен дать возможность редактировать строку ядра.
По дефолту — всё доступно без проблем.
This 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!
У меня один простой вопрос — почему вы сами тогда, «правильно и грамотно», не написали об этом? Очень легко критиковать публикации авторов, но у вас я не вижу ни одной таковой. Понимаете?
т.е. критиковать нельзя, так получается?
Аргумент «сперва добейся»?
Ответ прост: я не умею писать, поэтому не пишу. Но читать-то я умею.
Вы сами как оцениваете качество этого перевода?
Ответ прост: я не умею писать, поэтому не пишу. Но читать-то я умею.
Вы сами как оцениваете качество этого перевода?
Оцениваю выше ваших оскорблений. Разве я где-то написал что-то подобное тому, в чём вы пытаетесь меня упрекнуть? Нет.
Мой принцип простой: «Критикуешь — Предлагай, Предлагаешь — Делай». У вас только критика, исправлений автору вы не предложили, а ведь с этого стоило начать.
И ещё — если вы умный, стоит учить окружающих людей, делая таким образом лучше всем. Надменно упрекая вы лишь ускоряете общее движение в обратном направлении.
Мой принцип простой: «Критикуешь — Предлагай, Предлагаешь — Делай». У вас только критика, исправлений автору вы не предложили, а ведь с этого стоило начать.
И ещё — если вы умный, стоит учить окружающих людей, делая таким образом лучше всем. Надменно упрекая вы лишь ускоряете общее движение в обратном направлении.
Здравствуйте. Ну а что я могу предложить? К сожалению, Анастасия, похоже, не очень хорошо разбирается в теме статьи. Здесь чуть ли не каждый абзац надо переписывать. Мне почему-то не хочется выполнять за другого человека его (вероятно, оплачиваемую) работу.
Это в частности. А в общем у меня стандартное нытьё про слишком уж большое количество редакторских статей, на фоне которых приходится отыскивать крупицы от специалистов.
Это в частности. А в общем у меня стандартное нытьё про слишком уж большое количество редакторских статей, на фоне которых приходится отыскивать крупицы от специалистов.
Ну, вот так и получается, что, так как специалисты не считают нужным писать самостоятельно об интересных темах, приходится Анастасии (которая девушка далеко не глупая) вникать вот в такие вот вещи. Но, главное, это что Анастасия открыта к диалогу и вполне способна реагировать на нормальные замечания. Я понимаю, что вы, субъективно, всё бы переписали — я бы тоже написал иначе, но суть в том, что сделала это Анастасия, а не мы с вами.
Может быть прозвучит грубо и даже невежливо, т.к. говорим в третьем лице, но зачем Анастасия пишет о том, что ей не интересно? Ведь поленилась же хотя бы в Википедии почитать что такое Root. Здесь уже и в комментариях куча вопросов, которые по понятным причинам останутся без ответа от автора.
Выглядит так, как будто я нападаю на неё лично, но нет. Понятно, что девушка она не глупая, и вообще разбирается в вещах, хоть эта статья и переведена «на отстань».
Что меня больше удручает, так это большое количество таких статей, когда автор пишет не потому что хочет, а потому что надо «гнать контент».
Выглядит так, как будто я нападаю на неё лично, но нет. Понятно, что девушка она не глупая, и вообще разбирается в вещах, хоть эта статья и переведена «на отстань».
Что меня больше удручает, так это большое количество таких статей, когда автор пишет не потому что хочет, а потому что надо «гнать контент».
Вы правда считаете, что в данном конкретном случае уместно словосочетание «гнать контент»? Вроде, о важной вещи сообщили, интересной многим причастным. Да, были ошибки — их исправили. Всё-равно дать ответы на все вопросы в рамках одной публикации почти всегда невозможно. Между прочим, вы снова додумали — никто не говорил о том, что Анастасии эта тема не интересна :)
Да, считаю словосочетание абсолютно уместным. И не только в этом случае, а и ко многим статьям редакторов.
Ошибки не исправили. Как перевод не пометили.
Да, вещь важная, но на профильных ресурсах новость уже проходила, так что большинство уже в курсе. Заметка на OpenNet, например, на голову лучше, чем здесь. (Заодно посмотрите как переводятся встречающиеся в тексте термины).
Ошибки не исправили. Как перевод не пометили.
Да, вещь важная, но на профильных ресурсах новость уже проходила, так что большинство уже в курсе. Заметка на OpenNet, например, на голову лучше, чем здесь. (Заодно посмотрите как переводятся встречающиеся в тексте термины).
Очень удивительно что такую уязвимость только сейчас заметили.
Хотел испугаться и не успел. Сижу на тестинге, а там эту ошибку исправили ещё 7-го ноября:
http://metadata.ftp-master.debian.org/changelogs/main/c/cryptsetup/cryptsetup_1.7.3-2_changelog
Теперь после трёх неудачных попыток ввода пароля консоль блокируется на 1 минуту (по умолчанию).
http://metadata.ftp-master.debian.org/changelogs/main/c/cryptsetup/cryptsetup_1.7.3-2_changelog
Теперь после трёх неудачных попыток ввода пароля консоль блокируется на 1 минуту (по умолчанию).
Sign up to leave a comment.
Уязвимость скриптов инициализации Cryptsetup в Debian: достаточно просто зажать Enter