информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
За кого нас держат?Атака на Internet
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Очередное исследование 19 миллиардов... 
 Оптимизация ввода-вывода как инструмент... 
 Зловреды выбирают Lisp и Delphi 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / site updates
Имя Пароль
если вы видите этот текст, отключите в настройках форума использование JavaScript
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
Копай в сторону IDT, #GP. Кратко, первопричина в том, что sysret использует информацию из IDT. В случае косяков AMD вызывает исключение в госте, а вариация Intel в хосте. Погугли по "sysret intel vulnerability example". Ну, и запустится не процесс, а код. 19.06.12 11:16  Число просмотров: 1846
Автор: kstati <Евгений Борисов> Статус: Elderman
<"чистая" ссылка>
<site updates>
Повышение привилегий и побег из виртуалок из-за уязвимости в sysret на всех процессорах x86-64 от intel 18.06.12 20:01  
Publisher: leo <Леонид Юрьев> Статус: Elderman
<"чистая" ссылка>
Повышение привилегий и побег из виртуалок из-за уязвимости в SYSRET на всех процессорах x86-64 от Intel
US-CERT http://www.kb.cert.org/vuls/id/649219

Во всех процессорах архитектуры x86-64 от Intel есть уязвимость, позволяющая повышение привилегий до уровня ядра ОС или супервизора, включая выход за пределы виртуальной машины.
Уязвимость является следствием ошибки в реализации инструкции SYSRET, точнее, в некорректной проверке неканонического адреса перед сменой привилегий в 64-х битном режиме. Это позволяет выполнить произвольный код из Ring 3 (непривилегированный пользователь) в Ring 0 (ядро или супервизор).
В US-CERT обнаружили уязвимость еще в мае, уведомили вендоров и 12 июня опубликовали новость.


Полный текст
Это как работает вообще, я чтот не врубаюсь... 19.06.12 09:52  
Автор: HandleX <Александр М.> Статус: The Elderman
<"чистая" ссылка>
Например, на некоем хостинге мне выделили виртуальную машину.
Я на ней ставлю некую ось, и загружаю свой драйвер, который выполнит такой хитрый SYSRET, который запустит некий мой процесс на супервизоре, так я понимаю?
Да, но можно обойтись и без установки драйвера. 19.06.12 16:04  
Автор: leo <Леонид Юрьев> Статус: Elderman
<"чистая" ссылка>
Точно, спасибо. 20.06.12 11:45  
Автор: HandleX <Александр М.> Статус: The Elderman
<"чистая" ссылка>
Копай в сторону IDT, #GP. Кратко, первопричина в том, что sysret использует информацию из IDT. В случае косяков AMD вызывает исключение в госте, а вариация Intel в хосте. Погугли по "sysret intel vulnerability example". Ну, и запустится не процесс, а код. 19.06.12 11:16  
Автор: kstati <Евгений Борисов> Статус: Elderman
<"чистая" ссылка>
Почитал, разобрался... самое смешное, что интел говорит примерно следующее: "а мы чо — мы ничо, всё работает согласно нашим спецификациям" :-) всё верно — задокументированный баг уже не баг -))) 20.06.12 11:36  
Автор: HandleX <Александр М.> Статус: The Elderman
<"чистая" ссылка>
Баг после документирования становится фичей) 20.06.12 15:48  
Автор: Fighter <Vladimir> Статус: Elderman
<"чистая" ссылка>
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2025 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach