Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Directx 11 нашел свой пример который ломает графику Win 7 64bit. (2 стр)

Directx 11 нашел свой пример который ломает графику Win 7 64bit. (2 стр)

Поделиться

Страницы: 1 2 3 4 Следующая

nonamezeroxПостоялецwww14 ноя. 20175:35#15
Suslik
> попробуй найти минимальный код, который это воспроизводит. даже если какая-то
> одна версия дров это позволяет, то это уже может быть достаточно серьёзным
> эксплойтом.

Так кстати первый эксплойт для Xbox 360 работал. В игре Peter Jackson's King Kong цифровую подпись имел только основной xex'шник, а все файлы ресурсов, включая файлы шейдеров - нет. И путем замены шейдера на вредоносный, в котором, в силу его бинарности можно было спокойно задать любое смещение по памяти для записи, видеокарта ничтоже сумняшеся писала в системную память и запускала загрузчик линукса или иной другой код.

И тот же принцип уже был использован в первом "боевом" эксплойте (как раз тот самый jtag hack), с той лишь разницей, что использовалось в добавок к этой "фиче" сразу еще две уязвимости - отсутсвие проверки микрокода для платки с кнопкой включения и беспроводным модулем геймпадов и наличие отставленного включенным JTAG-вывода видеочипа. В результате нехитрой аппаратной схемы подпайки этого самого штатного контроллера к jtag порту штатной же видюхи и заливки программатором "правильной" прошивки в системную флешу, прошивка консоли ничего не подозревая заливала в  контроллер геймпадов эксплойт, который путем подпаянных проводов заливал через JTAG в видюшку шейдер, который уже писал в системную память.

SuslikМодераторwww14 ноя. 20176:49#16
nonamezerox
прохладная история, интересно. я понемногу следил за psp/ps vita сценой. там обычно хватало software-only эксплойтов, но использовали их тоже очень интересно. например, игры psp игры внутри ps vita запускались в отдельной виртуальной машине, поэтому даже если найти эксплойт в psp игре, то максимум, что можно было получить — доступ к виртуальной машине. так вот только спустя длительное время, когда этот доступ получили, они нашли эксплойт в коде самой виртуальной машины, чтобы уже оттуда выбраться в юзермод самой приставки.

Правка: 14 ноя. 2017 6:51

MrShoorУчастникwww14 ноя. 20177:33#17
nonamezerox
> в котором, в силу его бинарности можно было спокойно задать любое смещение по
> памяти для записи, видеокарта ничтоже сумняшеся писала в системную память и
> запускала загрузчик линукса или иной другой код.
Чет как то котолампово выглядит. Видеокарта обычно пишет в видеопамять. Даже можем предположить, что какие-то индусы сделали read back на цпу сторону. Но вот поверить в то, что результат ридбека поместили в executable память, и отправили цпу выполнять этот код - уж простите,  но тут явный кот с лампой.

Правка: 14 ноя. 2017 7:36

nonamezeroxПостоялецwww14 ноя. 20177:48#18
MrShoor
> Видеокарта обычно пишет в видеопамять

У бокса нет отдельной видеопамяти, да и если бы была, как на пс3 или пк, шарить оперативу никто не запрещает и адресное пространство оной видно для чтения и записи видеокартой. GL_DYNAMIC_COPY и GL_STREAM_COPY, собсно и работают за счет того, что видеокарта может из оперативы читать. Да и когда видеопамять кончается - тоже. И вся безопасность этой дыры держится исключительно на абстракции GAPI и драйве.
> Но вот поверить в то, что результат ридбека поместили в executable память

Executable, readble и прочие атрибуты существуют только в манямирке внутри MMU центрального процессора и таблиц страниц, для устройства на шине - это все тупо физическая память, причем как правило реализованы механизмы обхода когерентности кеша cpu, дабы это все добро вместе не тормозило.

> отправили цпу выполнять этот код

И собственно вот.

Правка: 14 ноя. 2017 8:07

MrShoorУчастникwww14 ноя. 201710:51#19
nonamezerox
> У бокса нет отдельной видеопамяти
Да, погуглил. Действительно нет.
> шарить оперативу никто не запрещает и адресное пространство оной видно для чтения и записи видеокартой.
Ну оно то не запрещает, но это все ляжет на плечи DMA контроллера, ты же понимаешь.

nonamezerox
> Executable, readble и прочие атрибуты существуют только в манямирке внутри MMU центрального процессора
> для устройства на шине - это все тупо физическая память,
Это понятно, но если код будет исполнятся в юзерспейсе центральным процессором, то эти проверки будут делаться как ни крути. Правильно?

nonamezerox
> И собственно вот.
Дык а как? Как этот код реально внедрить в CPU тред? Ну вот видеокарта нарендерила нам код в память. Кто все это дело будет "запускать" теперь? Да и зачем такие сложности с шейдером? Просто положил png/bmp картинку с кодом в ресурсы и все. Но до сих пор в интернете bmp картинки ходят неподписанные, и никого еще не заразили. Так как оно вообще работает с шейдером то?

Правка: 14 ноя. 2017 10:54

nonamezeroxПостоялецwww14 ноя. 201711:09#20
MrShoor
> но если код будет исполнятся в юзерспейсе центральным процессором

То мы пишем в таблицы страниц чтобы все окей было. У нас же с видеокарточки есть доступ ко всей физической памяти (а значит и к виртуальной памяти, и к памяти ядра и к таблицам страниц и к прочим ништякам)

> Дык а как? Как этот код реально внедрить в CPU тред?

Как как. Записью в память циферок по адресу где этот код находится. Нам же пофигу на MMU - он в процессоре и защиту обеспечивает только для CPU-кода.

> Ну вот видеокарта нарендерила нам код в память

Нарендерила в память, где находится текущий исполняемый програмный код. Адрес "текстурюниту" мы в нативном шейдере (который бинарными командами таргет-архитектуры GPU) можем задать.

> но это все ляжет на плечи DMA контроллера

DMA контроллер он немного про другое. Использовать его чтобы писать через pcie в ram не обязательно.

As for how, the PCI(e) bus allows any device to perform read/write to any address, be it in the main system ram ( typically controlled directly by the CPU these days ), or on some other device on the bus. That is, one PCI(e) device can directly access the memory or registers of another PCI(e) device, or main system ram, without regard to where it is located. The PCI(e) bridges route the request to the appropriate device, as they are configured ( by the system firmware/bios, and possibly later by the OS kernel ) to know what address ranges are "owned" by what device.

То есть любая штука, воткнутая в PCIe может спокойно хоть писать в память програмы, хоть в память таблицы страниц, хоть ломать систему, хоть форматировать хард,  хоть куда, на MMU процессора ей абсолюно плевать, он в процесоре и следит только за тем куда код на этом самом процессоре лазит, за прочими устройствами на шине он не следит.

Правка: 14 ноя. 2017 11:24

MrShoorУчастникwww14 ноя. 201718:08#21
nonamezerox
> Как как. Записью в память циферок по адресу где этот код находится. Нам же
> пофигу на MMU - он в процессоре и защиту обеспечивает только для CPU-кода.
Так а как технически это сделать то? Вот шейдер рендерит в текстуру или в structured буфер. Как вылезти за границы, чтобы оно еще и превратилось в dma пакеты с нужными адресами?
nonamezeroxПостоялецwww14 ноя. 201722:27#22
> Вот шейдер рендерит в текстуру или в structured буфер. Как вылезти за границы, чтобы оно еще и превратилось в dma пакеты с нужными адресами?

Использовать нативный код, в котором есть команды вроде MEM_EXPORT , как это и работало в эксплойте у бокса. 

Я уже третий раз объясняю, что рендеринг в текстуру или там буфер - это абстракция гапи- и только в рамках неё все так безопасно чинно благородно.  А внутри микрокода гпу там хаос, анархия, реал-мод доса и доступ ко всему. И если эта абстракция протечет (как это случилось у роннико) - то здравствуй жопа новый год.

http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AM… df#G13.454151

Вот тут видно, что мемори буфер определяется конкретно в регистре микрокодных ядер, с физическим адресом и прочими гейшами безо всяких макро-стейт абстракций.

И в отличии от х86, с его w^x, ALSR и прочими приколами аппаратно-програмного характера тут злоумышленника от возможности натворить бед отделяют лиш руки писавшего драйвер и  компилятор glsl/msil индуса.

> в dma пакеты

В дма-пакеты ничего преобразовывать не обязательно, если речь не о передаче данных в фоновом режиме . У любой шины, как у бокса так и у PCIe, есть отображенные в оперативу адрес, данные и команды записи чтения.  И с помощью шины можно и читать и писать.

Правка: 14 ноя. 2017 22:34

endeavour_prПостоялецwww14 ноя. 201722:28#23
ASMR relaxing ?
SuslikМодераторwww15 ноя. 20171:50#24
MrShoor
> Просто положил png/bmp картинку с кодом в ресурсы и все.
ты не поверишь, но именно так ломались некоторые версии прошивки psp: через tga, когда-то давно и вовсе не так давно — через tiff эксплойты.
ronnikoЗабаненwww15 ноя. 20176:19#25
Ломалка рабочего стола.
rar 4 метра.
https://ru.files.fm/u/b64ttnbb#_

Интересно что будет на NVIDIA карточках ?
Пишите какая винда и видеокарта.

Выйти из проги можно по Alt+F4.

Перезагрузите комп что бы избавиться от поломанного рабочего стола.

PS: Сломай свой рабочий стол !

Правка: 15 ноя. 2017 6:28

SuslikМодераторwww15 ноя. 20176:32#26
ronniko
я не думаю, что кто-то захочет качать бинарник от человека, который не может себе adblock поставить, не говоря уж malware-свалке у него на машине. выкладывай минимальный сорс.
ronnikoЗабаненwww15 ноя. 20176:36#27
А чего вы боитесь ? У вас же антивирусы, adblock-и стоят ?!
И руки растут из правильного места !

Правка: 15 ноя. 2017 6:37

SuslikМодераторwww15 ноя. 20177:12#28
ronniko
> И руки растут из правильного места !
именно поэтому нет никакого желания качать что попало.
AndreyПостоялецwww15 ноя. 20178:57#29
ronniko
D3DX10_33.dll может в системе отсутствовать.
Windows 10 X64, GeForce GT 610. Ничего не ломается.

Страницы: 1 2 3 4 Следующая

/ Форум / Программирование игр / Графика

2001—2017 © GameDev.ru — Разработка игр