Было в Talks:

Дырочка в процессорах интел

Но не обратили внимания никто.

Ещё бы ссылку на check.c какой-нибудь...

exploit.S где?

Ubuntu Unknown

А как проверить?

кастую, exploit в public.

sysret исполняется из ring0 => при желании ОС взять проверку адреса возврата на себя

Так что ждёт фиксов в ядре Linux

Это прелестно. А что, у них там при проектировании на HDL никаких тестов на реакцию на невалидные данные не применяется? Типа, забыли при проектировании проверить или просто не подумали - получай дыру.

Патчик для фряхи

http://security.freebsd.org/patches/SA-12:04/sysret.patch

Решето!

По ссылке уязвимости различных систем отсутствует информация наиболее вероятном противнике (шиндошс). Оно конечно к UNIX не имеет ни малейшего отношения, но на x86_64 вполне себе работает.

Да, товарщи! Такие проблемы столько лет не устранены. Это колоссольный крокол.

решето!

по ссылке не нашел, к каким конкретно моделям процессоров это относится. Неужто ко всем, в которых есть эта инструкция? :)

Ну не всё тестами покрыли

Ну вот. А мне кто-то ещё не верил что интел фигня и их не нужно покупать.

Но у меня на другом компе проц как раз интел, можно как-то пофиксить или только комп менять (впрочем пора пожалуй, он старый уже)?

По ссылке уязвимости различных систем отсутствует информация наиболее вероятном противнике (шиндошс).

Парадокс, но в этот раз они уже выпустили заплатки: бюллетень за июнь.

Сенсация! Новый блокбастер!

Во всех процессорах x86-64!

«Побег из Виртуальной Машины».

Спродюссировано лучшими инженерами Intel!

Но у меня на другом компе проц как раз интел, можно как-то пофиксить или только комп менять (впрочем пора пожалуй, он старый уже)?

У тебя на другом компе овер 100 человек каждый день пытаются повысить себе привелегии? Круто живешь, я смотрю.

побег из виртуальной машины

Ну всё, нам конец.

Это патч для хоста или гостя виртуалки?

Ядро ОС может защититься, если перед sysret (а он исполняется именно в ядре, в конце системного вызова) будет вручную проверять адрес возврата, а не полагаться на аппаратную проверку.

А что, у них там при проектировании на HDL никаких тестов на реакцию на невалидные данные не применяется?

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

Как хорошо, что у меня не Интел.

на HDL никаких тестов

тесты ничего не гарантируют, вот и получили дыру

Ну вот, опять при покупке процессоров придётся степинги проверять.
АМД рулит :D

процессоров Intel

Кому нужно это поделие? У приличных людей AMD.

А не получится, как у АМД с TLB на заре феномов? Софт-фикс то сделали, но производительность упала.

Ведь sysret именно для ускорения сделали аппаратным.

Такая серьезная организация, а про мою любимую семерочку вообще ничего не нет.

Да неужели?

This vulnerability only affects Intel x64-based versions of Windows 7 and Windows Server 2008 R2.

Ядро ОС может защититься, если перед sysret (а он исполняется именно в ядре, в конце системного вызова) будет вручную проверять адрес возврата, а не полагаться на аппаратную проверку.

А Linux с этим как (именно само ядро, не всякие гипервизоры)?

Не исключено, что они эту ошибку давно выявили, но решили не тратить средства на устранение, ибо лемминги и так будут потреблять и радоваться.

Очень похоже на правду. Прикинули издержки на решение проблемы и решили не поднимать шум.

Кто виноват, понятно. А делать-то что? Ждать обновления ядра? Потом как-то обновлять микрокод? Ну же, специалисты, разъясните толково!

Про «количество дыръ въ Intel'овскихъ процессорахъ давно уже стали притчей во языцахъ» уже вспоминали?

Это патч самого ядра FreeBSD. там используется модель безопасности rings, которая не так уж и безопасна на процах Intel :) btw. у меня amd

http://lists.freebsd.org/pipermail/freebsd-announce/2012-June/001425.html

Ну выпустят в итоге обновленный микрокод и всех делов.

А еще говорят, что mac os решето.

Я это уже не знаю. Я только знаю, что программно ядро имеет возможность защититься. Кто защиту уже сделал - понятия не имею.

Проверка каноничности адреса вроде не сложная. Надо только проверить, что адрес принадлежит промежутку от 0xFFFF800000000000 до 0x7FFFFFFFFFFF (ну это частный случай на самом деле, чисто теоретически допустимы другие промежутки, но вы не найдёте процессоров с шириной _виртуального_ адреса отличной от 48 бит). Если дело только в каноничности адреса, то это поможет.

Не думаю, что добавление 4-х ассемблерных команд (не считая кода прибивания процесса, если адрес не прошёл проверку) в конце системного вызова заметно снизит производительность.

Эту дыру возможно закрыть через ядро?

Кто это у тебя на аватарке?

Такие проблемы столько лет не устранены.

Скорее всего об этом знали соответствующие структуры и молчали.

Легко. Надо просто заменить все sysret на вот этот код:

mov rax, 0xFFFF800000000000
cmp rax, rcx
jbe lbl1
mov rax, 0x7FFFFFFFFFFF 
cmp rax, rcx
jbe lbl2
lbl1:
sysretq
lbl2:
; Код прибивания текущего процесса, потому что он сделал не то, что нужно

По ссылке уязвимости различных систем отсутствует информация наиболее вероятном противнике (шиндошс). Оно конечно к UNIX не имеет ни малейшего отношения, но на x86_64 вполне себе работает.

ЛОЛ, шиндошс уязвима на любом процессоре.

4 ассемблерных комманды - это совсем мало. Но как часто они будут вызываться? На среднем десктопе, может, ничего и не почувствуется, но при нагрузке в особенности на сервере?

Так вот почему у интела сейчас самые быстрые процы :) Они там просто жульничают.

локалхост спасен!

обновления микрокода где?

Не, после бага в мускуле это уже не так смешно

В обработчике системного вызова, написанном на ЯВУ количество команд измеряется сотнями и тысячами. 4 дополнительные не будут заметны.

Кто это у тебя на аватарке?

寶井 秀人