Re[11]: Кстати, об опере (hack2own)
От: vpchelko  
Дата: 29.05.12 18:15
Оценка:
Здравствуйте, stasgoo, Вы писали:
S>А я делаю далеко идущие выводы о твоём уровне. Т.к. все знают, что в BSOD/Kernel Panic систему уронить с UserMode невозможно. Это исключительно заслуга привелегированного кода (режим ядра). Схватил синяк — ищи виновный драйвер/железо. Предсказываю (с очень большой вероятностью) что виновником будет видеодрайвер, либо кривой антивирус.

Не обязательно драйвер управляет железкой. Всякие софтины используют самописные драйверы в качестве "защиты".
Сало Украине, Героям Сала
Re[12]: Кстати, об опере (hack2own)
От: Privalov  
Дата: 29.05.12 19:33
Оценка: +1 :)))
Здравствуйте, hattab, Вы писали:

s>> А я делаю далеко идущие выводы о твоём уровне. Т.к. все знают, что в BSOD/Kernel Panic систему уронить с UserMode невозможно. Это исключительно заслуга привелегированного кода (режим ядра).


H>Сюда нужно ходить с включенным чувством юмора


Возможно, это была попытка меня потроллить. Но, чтобы она была более успешной, нужно было правильно написать слово "привилегированный".
Re[2]: Кстати, об опере (hack2own)
От: ononim  
Дата: 29.05.12 22:58
Оценка: 2 (2)
O>А вообще, можно ли "сломать" браузер, если, к примеру, Java/Flash отключены, никакие
всяко бывает, бывает что и через картинки хакают:
http://www.securityfocus.com/bid/9663
http://technet.microsoft.com/en-us/security/bulletin/ms06-001
В любом коде парсящем данные (html, картинки, js etc) может быть баг, с возможностью эксплоитации и исполнения кода на том уровне, на котором работает парсер. С другой стороны — баг может и не быть Вероятность его наличия прямо пропорциональна количеству строк кода (от нуля до дохрена) помноженному на содержание индусов в тиме (от нуля до единицы), писавшем его, помноженное на степень их классичности (тоже от нуля до единицы).
Как много веселых ребят, и все делают велосипед...
Re[12]: Кстати, об опере (hack2own)
От: Lazytech Ниоткуда  
Дата: 30.05.12 06:25
Оценка:
Здравствуйте, okman, Вы писали:

O>Я месяц назад ловил BSOD на WinXP SP2 только из-за того, что в манифесте exe была не совсем

O>правильная строчка. А еще у меня есть довольно милый exe-шничек, чудным образом роняющий
O>практически любую версию в BSOD. Даже прожженный Server 2008 R2 SP1 и то падает.
O>Кернел модом там и близко не пахло. Так что возможно все.

Года полтора-два назад гарантированно ловил BSOD на WinXP SP2 при каждой попытке запустить Media Player Classic — Home Cinema. Что характерно, в моем случае это был единственный «плохой» плейер. На одном форуме мне объяснили, что его просто заточили под семерку, а на хрюше, похоже, не удосужились протестировать.
Re[13]: Кстати, об опере (hack2own)
От: stasgoo  
Дата: 30.05.12 09:23
Оценка:
Здравствуйте, Privalov, Вы писали:

P>Возможно, это была попытка меня потроллить. Но, чтобы она была более успешной, нужно было правильно написать слово "привилегированный".


Ай молодца! Улыбнул
Re[12]: Кстати, об опере (hack2own)
От: stasgoo  
Дата: 30.05.12 09:23
Оценка: 1 (1)
Здравствуйте, okman, Вы писали:

O>Я месяц назад ловил BSOD на WinXP SP2 только из-за того, что в манифесте exe была не совсем

O>правильная строчка.

С очень большой вероятностью — кривой драйвер антивируса, который имеет ошибку в PE парсере.

O>А еще у меня есть довольно милый exe-шничек, чудным образом роняющий

O>практически любую версию в BSOD. Даже прожженный Server 2008 R2 SP1 и то падает.
O>Кернел модом там и близко не пахло. Так что возможно все.

Кроме кернел-мода можно уничтожить critical system process, типа lsass. Тоже будет синяк.

Давай с другой стороны зайдём.
1) чистая система, Юзерский (не административный) аккаунт. Урони в синяк. Хрен у тебя что получится.
2) чуть расширим: система чистая, аккаунт админский. Если роняешь в синяк — 99.99% что рушишь системные процессы либо ставишь кривой драйвер. Давай сюда свой EXE, разберёмся.
3) совсем расширим: стоят сторонние драйвера. Тут в синяк может уронить любой чих, всё зависит от степени кривости драйвера.

И да, я в курсе что драйвер не обязательно связан с железом. Драйвер — любой модуль ядра.
Re[13]: Кстати, об опере (hack2own)
От: Privalov  
Дата: 30.05.12 09:48
Оценка:
Здравствуйте, stasgoo, Вы писали:

S>Давай с другой стороны зайдём.

S>1) чистая система, Юзерский (не административный) аккаунт. Урони в синяк. Хрен у тебя что получится.

Именно в таких условиях я увидел BSOD от Оперы. Я давно уже не сижу под админом в Винде. XP SP3, если что. Не анализировал, но дамп на всякий случай сохранил. Если будут повторы, тогда займусь.
Re[2]: Кстати, об опере (hack2own)
От: Vain Россия google.ru
Дата: 30.05.12 10:36
Оценка:
Здравствуйте, Zenden, Вы писали:

Z>Вот не пойму, как за непродолжительное время проведения конференции можно взломать браузер?

Z>Или они туда идут, имея шпаргалки с 0day-уязвимостями?
Естественно, подготовленными.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[13]: Кстати, об опере (hack2own)
От: okman Беларусь https://searchinform.ru/
Дата: 30.05.12 11:29
Оценка:
Здравствуйте, stasgoo, Вы писали:

S>С очень большой вероятностью — кривой драйвер антивируса, который имеет ошибку в PE парсере.


Нету там антивируса. Чистая Windows XP SP2 (5.1.2600.2180).
Проблема воспроизводится только на XP SP2, если заембеддить в exe манифест, сгенерированный
тулом mt.exe из последних SDK, поместив в него элементы dpiAware и compatibility.
Причем mt.exe нужен именно один из последних, из SDK для Vista не пойдет.
И BSOD получается не сразу, а обычно на второй-третий запуск.

S>Кроме кернел-мода можно уничтожить critical system process, типа lsass. Тоже будет синяк.


S>Давай с другой стороны зайдём.

S>1) чистая система, Юзерский (не административный) аккаунт. Урони в синяк. Хрен у тебя что получится.

Легко. У меня была простая программулина, которая просто выводила MAC-адрес сетевой карты, так она
стабильно роняла 2008-ой сервак (Server 2008 R2 SP1) в синий экран. При том, что админских прав
по умолчанию нет, на сервере включен "Admin Approval Mode". Ну разумеется, никаких драйверов или
даже IOCTL она не использовала, просто GetAdaptersAddresses и оконная процедура.

S>2) чуть расширим: система чистая, аккаунт админский. Если роняешь в синяк — 99.99% что рушишь системные процессы либо ставишь кривой драйвер. Давай сюда свой EXE, разберёмся.


Ты про win32k.sys что, никогда не слышал ? Всяких "казусов" в графической подсистеме, косвенно
имеющих отношение к данному драйверу, по сей день немерено.
См. здесь, например — http://www.rsdn.ru/forum/winapi/4401263.all.aspx
Автор: kero
Дата: 30.08.11
Re[14]: Кстати, об опере (hack2own)
От: stasgoo  
Дата: 30.05.12 12:53
Оценка:
Здравствуйте, okman, Вы писали:

O>Здравствуйте, stasgoo, Вы писали:


S>>С очень большой вероятностью — кривой драйвер антивируса, который имеет ошибку в PE парсере.


O>Нету там антивируса. Чистая Windows XP SP2 (5.1.2600.2180).

O>Проблема воспроизводится только на XP SP2, если заембеддить в exe манифест, сгенерированный
O>тулом mt.exe из последних SDK, поместив в него элементы dpiAware и compatibility.
O>Причем mt.exe нужен именно один из последних, из SDK для Vista не пойдет.
O>И BSOD получается не сразу, а обычно на второй-третий запуск.

XPSP2 со всеми апдейтами ? Ай не верю я тебе. Давай сюда свой мега-ЕХЕ.

S>>Кроме кернел-мода можно уничтожить critical system process, типа lsass. Тоже будет синяк.


S>>Давай с другой стороны зайдём.

S>>1) чистая система, Юзерский (не административный) аккаунт. Урони в синяк. Хрен у тебя что получится.

O>Легко. У меня была простая программулина, которая просто выводила MAC-адрес сетевой карты, так она

O>стабильно роняла 2008-ой сервак (Server 2008 R2 SP1) в синий экран. При том, что админских прав
O>по умолчанию нет, на сервере включен "Admin Approval Mode". Ну разумеется, никаких драйверов или
O>даже IOCTL она не использовала, просто GetAdaptersAddresses и оконная процедура.

Драйвер сетевой карты чей ? Подозреваю что не МС-овский. Если хочется разобраться — берём дамп падения, грузим символы, и смотрим кто виноват.

S>>2) чуть расширим: система чистая, аккаунт админский. Если роняешь в синяк — 99.99% что рушишь системные процессы либо ставишь кривой драйвер. Давай сюда свой EXE, разберёмся.


O>Ты про win32k.sys что, никогда не слышал ? Всяких "казусов" в графической подсистеме, косвенно

O>имеющих отношение к данному драйверу, по сей день немерено.

Графическая подсистема и видеодрайверы в частности вообще довольно сложные штуки. Малварщики очень их любят. Только MS оперативно чинит такие баги. А у NVidia, например, много лет подряд (может и до сих пор) был known issue падение на Terminal Services в Application Mode, и чинить они его не собирались. Мол, ставьте драйвер от МСа, он тормознее, но надёжнее. Типа, зачем вам наше быстрое 3Д на серверной системе ?

O>См. здесь, например — http://www.rsdn.ru/forum/winapi/4401263.all.aspx
Автор: kero
Дата: 30.08.11


Одно дело ошибка, у всех бывает. У МС достаточно редко. Другое — косяк в дизайне.
Re[14]: Кстати, об опере (hack2own)
От: stasgoo  
Дата: 30.05.12 12:54
Оценка:
Здравствуйте, Privalov, Вы писали:

P>Здравствуйте, stasgoo, Вы писали:


S>>Давай с другой стороны зайдём.

S>>1) чистая система, Юзерский (не административный) аккаунт. Урони в синяк. Хрен у тебя что получится.

P>Именно в таких условиях я увидел BSOD от Оперы. Я давно уже не сижу под админом в Винде. XP SP3, если что. Не анализировал, но дамп на всякий случай сохранил. Если будут повторы, тогда займусь.


Открой дамп с помощью WinDbg — с большой вероятностью в стеке увидишь виновника. Если сам не умеешь — выложи, я посмотрю.
Re[15]: Кстати, об опере (hack2own)
От: okman Беларусь https://searchinform.ru/
Дата: 30.05.12 13:33
Оценка:
Здравствуйте, stasgoo, Вы писали:

S>XPSP2 со всеми апдейтами ? Ай не верю я тебе. Давай сюда свой мега-ЕХЕ.


"Голая" Windows XP SP2, никаких апдейтов, программ или драйверов.
Бинарник я выкладывать не буду, дабы не обвинили меня потом в рассылке malware.
Но вот как собрать его в домашних условиях, расскажу.

Берем любой exe-шник. Ну например, я взял notepad.exe.
Рядом с ним кладем файл notepad.exe.manifest со следующим содержимым:
  >НАЖАТЬ<
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

    <assemblyIdentity
        version="1.0.0.0"
        processorArchitecture="x86"
        name="MyCompany.MyProduct.notepad"
        type="win32">
    </assemblyIdentity>

    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
        <security>
            <requestedPrivileges>
                <requestedExecutionLevel
                    level="asInvoker"
                    uiAccess="false">
                </requestedExecutionLevel>
            </requestedPrivileges>
        </security>
    </trustInfo>

    <application
        xmlns="urn:schemas-microsoft-com:asm.v3">

        <windowsSettings>
            <dpiAware
                xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true
            </dpiAware>
        </windowsSettings>

    </application>

    <ms_compatibility:compatibility
        xmlns:ms_compatibility="urn:schemas-microsoft-com:compatibility.v1" 
        xmlns="urn:schemas-microsoft-com:compatibility.v1">

        <ms_compatibility:application
            xmlns:ms_compatibility="urn:schemas-microsoft-com:compatibility.v1">

            <ms_compatibility:supportedOS
                xmlns:ms_compatibility="urn:schemas-microsoft-com:compatibility.v1" 
                Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}">
            </ms_compatibility:supportedOS>

            <ms_compatibility:supportedOS
                xmlns:ms_compatibility="urn:schemas-microsoft-com:compatibility.v1" 
                Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}">
            </ms_compatibility:supportedOS>

        </ms_compatibility:application>

    </ms_compatibility:compatibility>

</assembly>

Практически идентичный XML генерируется тулом mt.exe из последних SDK, кстати говоря.
Все, готово. Запускаем exe. Первый запуск — все ок. Запускаем второй раз — BSOD.
У меня это поведение воспроизводится стабильно, что на "живой" XP, что на виртуальной.
Причем дело даже до entry point не доходит.

S>Драйвер сетевой карты чей ? Подозреваю что не МС-овский. Если хочется разобраться — берём дамп падения, грузим символы, и смотрим кто виноват.


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

S>Графическая подсистема и видеодрайверы в частности вообще довольно сложные штуки. Малварщики очень их любят. Только MS оперативно чинит такие баги. А у NVidia, например, много лет подряд (может и до сих пор) был known issue падение на Terminal Services в Application Mode, и чинить они его не собирались. Мол, ставьте драйвер от МСа, он тормознее, но надёжнее. Типа, зачем вам наше быстрое 3Д на серверной системе ?


O>>См. здесь, например — http://www.rsdn.ru/forum/winapi/4401263.all.aspx
Автор: kero
Дата: 30.08.11


S>Одно дело ошибка, у всех бывает. У МС достаточно редко. Другое — косяк в дизайне.


Понимаешь, тут кое-кто, — так и быть, укажем пальцем
Автор: stasgoo
Дата: 29.05.12
, — был немного опрометчив в заявлениях,
что "в BSOD/Kernel Panic систему уронить с UserMode невозможно". Как видим, можно.
Хотя бы по вине ошибок внутри самой Windows.
Re[16]: Кстати, об опере (hack2own)
От: stasgoo  
Дата: 30.05.12 14:47
Оценка:
Здравствуйте, okman, Вы писали:

O>Здравствуйте, stasgoo, Вы писали:


S>>XPSP2 со всеми апдейтами ? Ай не верю я тебе. Давай сюда свой мега-ЕХЕ.


O>"Голая" Windows XP SP2, никаких апдейтов.


Дальше, собственно, можно не читать. Потому что:
1) неактуально. Даже если ошибка была — сто тыщ раз уже исправлена за минувшие 7 (или 8?) лет.
2) хрен воспроизведёшь. Но я проверил на своей виртуалке. XPSP2 со всеми апдейтами. Разумеется никакого падения нет. Ни со второго, ни с 20-го запуска.

O>Понимаешь, тут кое-кто, — так и быть, укажем пальцем
Автор: stasgoo
Дата: 29.05.12
, — был немного опрометчив в заявлениях,

O>что "в BSOD/Kernel Panic систему уронить с UserMode невозможно". Как видим, можно.

Продолжаю утверждать что невозможно. Уронил (что ещё не проверено) не твой код, а ошибка в драйвере режима ядра. Пусть и в микрософтовском драйвере. Как именно происходила работа с драйвером — не суть важно.
Re[16]: Кстати, об опере (hack2own)
От: stasgoo  
Дата: 30.05.12 14:48
Оценка:
Здравствуйте, okman, Вы писали:

O>Берем любой exe-шник. Ну например, я взял notepad.exe.

O>Рядом с ним кладем файл notepad.exe.manifest со следующим содержимым:

Если у тебя всё так отлично воспроизводится — давай сюда системный minidump (а лучше fulldump), чтобы говорить более предметно.
Re[17]: Кстати, об опере (hack2own)
От: okman Беларусь https://searchinform.ru/
Дата: 30.05.12 17:29
Оценка:
Здравствуйте, stasgoo, Вы писали:

O>>"Голая" Windows XP SP2, никаких апдейтов.


S>Дальше, собственно, можно не читать. Потому что:


Читать надо было раньше. Цитата (okman): чистая Windows XP SP2 (5.1.2600.2180).
Да, я проверял на том же SP3 — баг уже не воспроизводится. BSOD ловится только на XP SP2 без апдейтов.
На всех новых системах его, разумеется, тоже нету. Но это ведь не суть дискуссии, верно ?
Ты же отстаиваешь принципиальную невозможность уронить систему в BSOD из user mode.
Я тебе привожу факты, доказывающие, что это возможно. Механизмы, лежащие в основе BSOD-а,
вторичны, поскольку инициируется BSOD вполне "правомерными" действиями, не выходящими из user
mode (обращение к оконным функциям, манифест приложения и т.п.). Ну или я тогда не
понимаю, о чем вообще мы спорим.

S>1) неактуально. Даже если ошибка была — сто тыщ раз уже исправлена за минувшие 7 (или 8?) лет.


По ссылке, которую я приводил выше, люди воспроизводили BSOD на "Семерке" со всеми апдейтами.
У всех наверняка были разные конфигурации, разный набор драйверов, и т.д. То есть, данное
поведение с большой вероятностью можно повторить на произвольно взятой системе.
Или Windows 7 — это сейчас тоже неактуально ?

S>2) хрен воспроизведёшь. Но я проверил на своей виртуалке. XPSP2 со всеми апдейтами. Разумеется никакого падения нет. Ни со второго, ни с 20-го запуска.


См. выше. Чистая Windows XP SP2.
Я не ручаюсь, что поведение у всех будет воспроизводиться — может, там еще какие-то специфические
факторы влияния. Например, разрешение экрана или глубина цвета. Не знаю. Но на тех системах, к
которым я имею доступ, наблюдаю BSOD вот с таким сообщением:

STOP: c000021a {
} ЌҐЇаҐ¤ўЁ¤Ґ­­®Ґ § ўҐа襭ЁҐ бЁб⥬­®Ј® Їа®жҐбб  Windows SubSystem
б б®бв®п­ЁҐ¬ 0xc0000005 (0x7c9106c3 0x00ceec24).
Џа®Ё§ўҐ¤Ґ­® § ўҐа襭ЁҐ а Ў®вл бЁб⥬л.

Это не ошибка RSDN — на "синем экране" действительно показываются такие символы.

O>>Понимаешь, тут кое-кто, — так и быть, укажем пальцем
Автор: stasgoo
Дата: 29.05.12
, — был немного опрометчив в заявлениях,

O>>что "в BSOD/Kernel Panic систему уронить с UserMode невозможно". Как видим, можно.

S>Продолжаю утверждать что невозможно. Уронил (что ещё не проверено) не твой код, а ошибка в драйвере режима ядра. Пусть и в микрософтовском драйвере. Как именно происходила работа с драйвером — не суть важно.


Ты, похоже, не читаешь, что тебе пишут. Как раз то, кто уронил систему, — драйвер или не
драйвер, — и не важно. Важно, что инициатором этого падения был код user mode.

Вот output из WinDbg, если интересно:
  >КЛАЦ<

*** An Access Violation occurred in C:\WINDOWS\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,3072,512 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=Off MaxRequestThreads=16:

The instruction at 7C9106C3 tried to write to an invalid address, 75E6193E

*** enter .exr 00CEEC08 for the exception record
*** enter .cxr 00CEEC24 for the context
*** then kb to get the faulting stack

Break instruction exception — code 80000003 (first chance)
ntdll+0x1230:
001b:7c901230 cc int 3
1: kd> g


Process.Thread : 000007D8.000007F0 (vmicsvc.exe) is trying to create key:
ObjectAttributes = 005BF590
The caller should not rely on data written to the registry after shutdown...


Process.Thread : 000007D8.000007F0 (vmicsvc.exe) is trying to create key:
ObjectAttributes = 005BF600
The caller should not rely on data written to the registry after shutdown...


Process.Thread : 000007D8.000007F0 (vmicsvc.exe) is trying to create key:
ObjectAttributes = 005BF590
The caller should not rely on data written to the registry after shutdown...

*** Fatal System Error: 0xc000021a
(0xE1E8E260,0xC0000005,0x7C9106C3,0x00CEEC24)


STOP: c000021a {
} ЌҐЇаҐ¤ўЁ¤Ґ­­®Ґ § ўҐа襭ЁҐ бЁб⥬­®Ј® Їа®жҐбб  Windows SubSystem
б б®бв®п­ЁҐ¬ 0xc0000005 (0x7c9106c3 0x00ceec24).
Џа®Ё§ўҐ¤Ґ­® § ўҐа襭ЁҐ а Ў®вл бЁб⥬л.
Break instruction exception — code 80000003 (first chance)

A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.

A fatal system error has occurred.

Connected to Windows XP 2600 x86 compatible target at (Wed May 30 20:08:19.125 2012 (UTC + 3:00)), ptr64 FALSE
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntkrpamp.exe —
Loading Kernel Symbols
...............................................................
.................................
Loading User Symbols

Loading unloaded module list
......
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck C000021A, {e1e8e260, c0000005, 7c9106c3, ceec24}

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

------------------------------------------------
| |
| NT symbols are not available |
| |
------------------------------------------------
*** ERROR: Module load completed but symbols could not be loaded for mssmbios.sys
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
Probably caused by : ntkrpamp.exe ( nt!KeRegisterBugCheckReasonCallback+77c )

Followup: MachineOwner
---------

nt!DbgBreakPointWithStatus+0x4:
8052a5d8 cc int 3
1: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

WINLOGON_FATAL_ERROR (c000021a)
The Winlogon process terminated unexpectedly.
Arguments:
Arg1: e1e8e260, String that identifies the problem.
Arg2: c0000005, Error Code.
Arg3: 7c9106c3
Arg4: 00ceec24

Debugging Details:
------------------

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

------------------------------------------------
| |
| NT symbols are not available |
| |
------------------------------------------------
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************

ADDITIONAL_DEBUG_TEXT: Windows SubSystem

MODULE_NAME: nt

FAULTING_MODULE: 804d7000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 41107b0d

BUGCHECK_STR: 0xc000021a_csrss.exe_c0000005

DEFAULT_BUCKET_ID: DRIVER_FAULT

LAST_CONTROL_TRANSFER: from 804f96e8 to 8052a5d8

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
baceb954 804f96e8 00000003 80561f70 00000001 nt!DbgBreakPointWithStatus+0x4
bacebd34 804f9c37 0000004c c000021a baac79b0 nt!KeRegisterBugCheckReasonCallback+0x77c
bacebd54 8064eb67 0000004c c000021a baac79b0 nt!KeBugCheckEx+0x1b
bacebd7c 80537757 00000000 00000000 8a751340 nt!MmMapUserAddressesToPage+0x31d3
bacebdac 805ce794 00000000 00000000 00000000 nt!ExQueueWorkItem+0x1a3
bacebddc 805450ce 80537668 00000000 00000000 nt!PsRemoveCreateThreadNotifyRoutine+0x214
00000000 00000000 00000000 00000000 00000000 nt!KiDispatchInterrupt+0x72e


STACK_COMMAND: kb

FOLLOWUP_IP:
nt!KeRegisterBugCheckReasonCallback+77c
804f96e8 e8cf790000 call nt!ZwYieldExecution+0xa64 (805010bc)

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: nt!KeRegisterBugCheckReasonCallback+77c

FOLLOWUP_NAME: MachineOwner

IMAGE_NAME: ntkrpamp.exe

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner
---------

Re: Кстати, об опере (hack2own)
От: Anton Batenev Россия https://github.com/abbat
Дата: 31.05.12 00:28
Оценка: +1
Здравствуйте, kochetkov.vladimir, Вы писали:

k> Делаем ставки?


Будет очень интересно узнать результат. Если будет время, напиши побольше.
avalon 1.0rc3 build 430, zlib 1.2.3.4
Re[2]: Кстати, об опере (hack2own)
От: Eugeny__ Украина  
Дата: 31.05.12 05:58
Оценка:
Здравствуйте, Anton Batenev, Вы писали:

AB>Будет очень интересно узнать результат. Если будет время, напиши побольше.


Присоединяюсь. Несмотря на то, что результаты ожидаются неутешительные, почитать их будет интересно. Хотя, врядли это помешает мне пользоваться Оперой в ближайшее время.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[18]: Кстати, об опере (hack2own)
От: stasgoo  
Дата: 31.05.12 09:17
Оценка:
Здравствуйте, okman, Вы писали:

O>Ты же отстаиваешь принципиальную невозможность уронить систему в BSOD из user mode.


Именно так, usermode не может уронить систему в BSOD.

O>Я тебе привожу факты, доказывающие, что это возможно. Механизмы, лежащие в основе BSOD-а,

O>вторичны

У нас явное противоречие взглядов на то, что является первичным, а что вторичным. В остальном ты пишешь тоже самое, что и я.

O>, поскольку инициируется BSOD вполне "правомерными" действиями, не выходящими из user

O>mode (обращение к оконным функциям, манифест приложения и т.п.). Ну или я тогда не
O>понимаю, о чем вообще мы спорим.

Спасибо капитан, только в этом случае в BSOD роняет систему вовсе не юзермод, а ядерный код. И не важно чем инициированы эти действия. Потому что, очевидно, решающим будет некорректное поведение (чаще всего банальная ошибка) ядерного кода.

Иными словами как бы не пыжилась опера или даже малварь — в БСОД систему она уронит только если будет исполнен некорректный код режима ядра. Степень явности его исполнения роли не играет. А от наличия ошибок никто не застрахован.

"В самой лучшей ОС" (ц) ядерные баги пачками каждый месяц находят, некоторые по 8 лет живут.

К чести МС свои баги она правит весьма оперативно.

O>Вот output из WinDbg, если интересно:


Похоже на правду, т.к. манифесты проверяются в csrss. Но всё-таки хотелось бы full memory dump. Можешь куда-нить на deposit files выложить в архиве ?
Re[19]: Кстати, об опере (hack2own)
От: okman Беларусь https://searchinform.ru/
Дата: 31.05.12 10:45
Оценка:
Здравствуйте, stasgoo, Вы писали:

S>Именно так, usermode не может уронить систему в BSOD.


S>У нас явное противоречие взглядов на то, что является первичным, а что вторичным. В остальном ты пишешь тоже самое, что и я.


Собственно, тут противоречий и нет. Юзер-модный код не может "сам" позвать KeBugCheck(Ex), —
и я рассчитываю на то, что ты понимаешь, что я это понимаю, — но он может это дело
"делегировать" какому-нибудь хитро составленному IOCTL-у для "дырявого" драйвера или
использовать другие косвенные методы.

В контексте того вопроса, из-за которого все и началось (BSOD в Opera), такие различия в
формулировках существенны. По-моему, здесь допустимо считать, что "Opera вызвала BSOD",
если в ней был исполнен код, приведший впоследствии к выбросу исключения и вызову bug check
routine где-то глубоко в недрах ядра.

S>Похоже на правду, т.к. манифесты проверяются в csrss. Но всё-таки хотелось бы full memory dump. Можешь куда-нить на deposit files выложить в архиве ?


Стал бы я эту муть с манифестами выдумывать ?
Выложу, надо только решить куда именно.
Потом опубликую ссылку здесь.
Re[19]: Кстати, об опере (hack2own)
От: okman Беларусь https://searchinform.ru/
Дата: 31.05.12 13:27
Оценка:
Здравствуйте, stasgoo.

Отправил приватное сообщение.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.