В ядре Linux найдена (https://www.openwall.com/lists/oss-security/2019/02/02/3) уязвимость (CVE-2019-7308 (https://security-tracker.debian.org/tracker/CVE-2019-7308)), позволяющая (https://bugs.chromium.org/p/project-zero/issues/detail?id=1711) обойти защиту от проведения атак класса Spectre v1 через использование подсистемы eBPF. Проблема устранена в выпусках ядра 4.19.19 и 4.20.6, но в дистрибутивах пока остаётся неисправленной (Debian (https://security-tracker.debian.org/tracker/CVE-2019-7308), RHEL (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-7308), SUSE (https://bugzilla.novell.com/show_bug.cgi?id=CVE-2019-7308), Ubuntu (https://people.canonical.com/~ubuntu-security/cve/CVE-2019-7308)).
Для чтения данных из привилегированных областей памяти при помощи атаки Spectre v1 необходимо наличие в привилегированном коде определённой (https://www.opennet.me/opennews/art.shtml?num=49015) последовательности (https://www.opennet.me/opennews/art.shtml?num=48956) команд (https://www.opennet.me/opennews/art.shtml?num=48639). Подобные сочетания команд были удалены из ядра Linux, но разработчики не учли то, что подсистема eBPF позволяет инициировать выполнение в контексте ядра произвольных BPF-программ. Через манипуляцией с байткодом BPF атакующий может добиться выполнения JIT-компилятором eBPF необходимого для совершения атаки Spectre v1 сочетания машинных инструкций, приводящих к спекулятивному обращению к внешним областям памяти при совершении операций с указателем.
Дополнительно, можно отметить предложение (https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/...) включить в состав ядра Linux патч, реализующий дополнительный режим для отключения базирующейся на использовании PSTATE-бита SSBS (Speculative Store Bypass Safe) защиты от атак Spectre. Подобная защита ощутимо снижает производительность, поэтому включается на уровне приложения при помощи команды PR_SET_SPECULATION_CTRL в prctl (как правило, атаке подвержены программы с JIT, например, Java). Проблема в том, что при отключении спекулятивных операций, данное состояние наследуется и для дочерних процессов. Для отключения наследования защиты (наследования блокировки спекулятивных операций) при запуске новых процессов предложен флаг PR_SPEC_DISABLE_NOEXEC.
URL: https://www.openwall.com/lists/oss-security/2019/02/02/3
Новость: https://www.opennet.me/opennews/art.shtml?num=50088
Поясните мне, я тупенький, это что опять процессоры понерфятся из-за патча от этой фигни? Причём предлагают прямо в ядро запилить, т.е. чтоб отключить это чудо надо будет ядро пересобирать или где?
читай новость ещё раз. уязвимость в ядре, в ядро и запилят исправление. или тебе иной путь представляется?
Подозреваю, что на производительности (как и на работе программ в целом) это вообще никак не скажется.
Интересно, а есть ли хотя бы один массовый случай взлома чего бы то ни было с использованием этих атак? Или вот-вот будет, вот завтра уже, вот готово почти? Такая буря, да, кажется, лишь в стакане.
Так эту хрень (tcp стек загружаемый в ядро jit компилятором из под пользователя) только-только стали завозить в обязательном порядке. Поэтому и нет атак. Вот будет в каждом rhel, тогда можно будет про случаи массового взлома рассуждать.
С учетом массовости облаков, массовые взломы могут быть ну очень массовыми.
И опять "могут быть". Вай, баюс-баюс, побежал за новым Intel Core i1488, где эта ошибка "исправлена", но через пару лет снова откроется. АТО Путин нападёт^W^W данные украдут!
проблема этих штук в том, что ты не узнаешь - в отличие от типовых атак, которые, даже если ограничились только чтением чего неположенного, все равно могут оставить на память трейсы в логах и прочие подозрительные следы, если не идеально пошло с первого раза, тут будет только повышенная ненадолго загрузка процессора.
поймать такое за ручку - сложно.
А вполне работающих p-o-c - было.
"ненадолго" с учётом потенциальной скорости чтения в реальных условиях в пару байт в час - это громко сказано.
так они ж никуда не торопятся - и потом, какой длины у тебя, скажем, пароль от банковской учетки? Ну и вот...да и в час - это слишком уж хорошее предположение. Как бы не в минуту.
В минуту даже meltdown не умеет, даже в почти идеальных условиях.
А загрузка CPU на приличное время на серверах будет засечена мониторингом, на десктопе - ушами.
А ничего что смысл нахождения уязвимростей в том, чтоб таких случаев небыло?
> А ничего что смысл нахождения уязвимростей в том, чтоб таких случаев небыло?это тебя кто-то сильно обманул. смысл нахождения уязвимостей в современном мире — это дать красивое имя и позволить продавать «ещё более защищённые системы».
Более красивое говно в более говняной упаковке.
Встречайте Intel Ujdyj Cegth.
> Интересно, а есть ли хотя бы один массовый случай взлома чего бы
> то ни было с использованием этих атак? Или вот-вот будет, вот
> завтра уже, вот готово почти? Такая буря, да, кажется, лишь в
> стакане.нет, не было и не будет. это булшит. за возможным исключением всяких SaaS-систем, где путём обмана потребителя и шаринга всего, чего можно, делают вид, что дают полноценную систему. но бесполезную «защиту» будут вкатывать всем.
Я правильно понимаю, что пока не сменится поколение нынешних процессоров, выпуск патчей против Spectre/Meltdown - это война с ветряными мельницами?..
Нет ничего более постоянного, чем временное. Пока памяти в кеше не будет, хоть ... ешь - её будут шарить, пока времени на все проверки не будет, для обработки операции и будут брать любой расшаренный кусок...
В Coffee Lake часть атак пофиксили на аппаратном уровне, но, в целом, надо кардинально перепиливать архитектуру, а это будет только в следующем поколении.
А что там с AMD Zen2?"For Spectre Variant 1, we continue actively working with our ecosystem partners on mitigations, including operating system patches that have begun to roll out," said Su.
She added that AMD continues to believe that variant 2 of Spectre is difficult to exploit on its processors but added that it is "deploying CPU microcode patches -- in combination with OS updates ― to provide additional mitigation steps".
"Longer term, we have included changes in our future processor cores, starting with our Zen 2 design, to further address potential Spectre-like exploits," she said. Zen 2 is the next generation of AMD X86 processors, based on 7nm technology and due to arrive in 2019.
Говно вопрос, списываем убытки на "ошибки аппаратной реализации" и закупаем новые процы, с "перепиленной" архитектурой.
Кто оплачивает банкет?
когда они уже наконец придут к выводу, что сама по себе ос - уязвимость? ведь она позволяет исполнять произвольный код
с разморозкой. пока ты потчевал к этому приходили и неоднократно. к чему по-твоему Microsoft внедрила DEP начиная с Windows XP? к чему LSM и AppArmor? к чему SELinux? к чему Grsecurity?
> пока ты потчевалкого потчевал, таракан? чем?
автокомплитом
> автокомплитомну так не употребляй умных слов, которые путают твоего робота. он хоть и умнее тебя, но всё ещё дурак.
Автодополнение в родном языке используют слабаки )
и люди с толстыми пальцами :(
это все не достаточно кардинально. они по прежнему позволяют исполнять код на процессоре.
выключи и поломай компьютер, чтоб кардинально исключить возможность выполнить на нём произвольный код
да нет, зачем - просто выруби там вайфай, блютуз, выдерни ethernet,
модем и встань с топором рядом, штоб никто не подошёл - влэшку не засунул
или диск. или дискету. тогда вроде совсем безопасно будет !
>когда они уже наконец придут к выводу, что сама по себе ос - уязвимость? ведь она позволяет исполнять произвольный кодкогда они уже наконец придут к выводу, что процессор, продающийся десятки лет - уязвимость? ведь он позволяет исполнять произвольный код независимо от операционной системы.
Ос не позволяет выполнять "произвольный код". Только в своей песочнице.
Ты из MSDOS приехал?
Наш Эльбрус на высоте!
Также радуюсь за отечество, наконец-то мы утёрли нос западникам!
Вы ведь понимаете что он не достаточно ещё исследован просто, да? Или серьёзно кто-то может так туго соображать?
Месье не умеет в иронию?
Главное - не забыть knob для отключения этого счастья.
ebpf-то? Ну, вроде как, еще пока можно ведро собрать без него. Скоро доломают.
Не eBPF. Митигаций Spectre в eBPF. Потому что мне допустим в роутере на X гиг оно как собаке пятая нога.
Интересно почему патч ещё не принят? Чего ждут то?
ты правда думаешь что я на своем макбучеке использую ebpf?
> но разработчики не учли то, что подсистема eBPF позволяет инициировать выполнение в контексте ядра произвольных BPF-программ:facepalm:
Это же как интел промыл всем мозги...
Вы покупали десятки лет дырявое интелловое говно, а тут оппа...