Что же тогда? Архитектурная особенность! Речь пойдет об уязвимостях.
Каждый кто хотя бы как-то относится к computer security знает, что типов уязвимостей довольно много.
Это buffer/heap/integer overflows, format string vulnerabilities, use after free, race conditions и так далее, имя им легион.
Но всех их объединяет одна вещь - так или иначе, они могут быть выявлены автоматически/полуавтоматически, либо на этапе компиляции( компиляторы, статические анализаторы и т.д. ), либо по методу черного ящика ( fuzzing, binary code analysis и т.д. ).
Однако есть один тип уязвимости выбивающийся из общего ряда и выявить подобные уязвимости может только человек, потому как они существуют на более высоком уровне абстракции - на уровне архитектуры.
Мне вспомнилось всего два примера таких уязвимостей, это:
1) (MS06-001) уязвимость в Windows Metafile files (.wmf) файлах
"Архитектурная особенность" в данной уязвимости позволяет абсолютно документированно содержать код в .wmf файлах и выполнять его, причем сидела эта ф-ция незамеченной со времен Windows 3.0 с 1990го года по 2006й, 16 лет.
2) (MS10-046) уязвимость в .lnk файлах, которую явил миру Stuxnet.
"Архитектурная особенность" в библиотеке shell32.dll приводит к тому, что открываемый ярлык (.lnk файл) приводит к загрузке и выполнению explorer'ом вредоносной .dll(для так называемые dynamic icons) путь к которой содержится в нем же самом.
Эта же особенность, но уже в самом формате .lnk файла позволяет файлу находиться вобще на удаленном компе ( Lnk File Format => File Location Info => Offset to the network volume table => Network share name ) в расшаренных папках.
Такого рода уязвимости будут всегда находиться только человеком, по крайней мере до тех пор, пока не придумают AI :)
p.s. Если вспомните еще какие-либо уязвимости подобного типа - пишите в комментах.
Каждый кто хотя бы как-то относится к computer security знает, что типов уязвимостей довольно много.
Это buffer/heap/integer overflows, format string vulnerabilities, use after free, race conditions и так далее, имя им легион.
Но всех их объединяет одна вещь - так или иначе, они могут быть выявлены автоматически/полуавтоматически, либо на этапе компиляции( компиляторы, статические анализаторы и т.д. ), либо по методу черного ящика ( fuzzing, binary code analysis и т.д. ).
Однако есть один тип уязвимости выбивающийся из общего ряда и выявить подобные уязвимости может только человек, потому как они существуют на более высоком уровне абстракции - на уровне архитектуры.
Мне вспомнилось всего два примера таких уязвимостей, это:
1) (MS06-001) уязвимость в Windows Metafile files (.wmf) файлах
"Архитектурная особенность" в данной уязвимости позволяет абсолютно документированно содержать код в .wmf файлах и выполнять его, причем сидела эта ф-ция незамеченной со времен Windows 3.0 с 1990го года по 2006й, 16 лет.
2) (MS10-046) уязвимость в .lnk файлах, которую явил миру Stuxnet.
"Архитектурная особенность" в библиотеке shell32.dll приводит к тому, что открываемый ярлык (.lnk файл) приводит к загрузке и выполнению explorer'ом вредоносной .dll(для так называемые dynamic icons) путь к которой содержится в нем же самом.
Эта же особенность, но уже в самом формате .lnk файла позволяет файлу находиться вобще на удаленном компе ( Lnk File Format => File Location Info => Offset to the network volume table => Network share name ) в расшаренных папках.
Такого рода уязвимости будут всегда находиться только человеком, по крайней мере до тех пор, пока не придумают AI :)
p.s. Если вспомните еще какие-либо уязвимости подобного типа - пишите в комментах.
Когда-то давным-давно ещё IDT вроде с 3-го ринга позволялось редактировать. Не помню, во времена какого царя гороха это было.
ОтветитьУдалитьбыло еще нечто подобное, но не в винде, а в эпловском квиктайме
ОтветитьУдалитьhttp://www.theregister.co.uk/2010/08/30/apple_quicktime_critical_vuln/
Ага, забавный бекдор, спасибо
ОтветитьУдалитьИнтересный пост!
ОтветитьУдалитьНа мой взгляд, их можно называть логическими ошибками(хотя под это может подойти RC) - так что лучше архитектурная фича :)
Имхо, MS10-046 - эта уязвимость может быть найдена автоматизированными средствами, так как модель уязвимости можно чётко описать(своего рода сигнатура для статического анализатора): данные под контролем атакующего идут в параметр ф-ии LoadLibrary.
Самая громкая архитектурная фича, на мой взгяд - MS10-015, найденная и проэксплуатированная небезизвестным Тэвисом Орманди.
Я имел ввиду поиск уязвимости _до_ ее эксплуатации, а не после :)
ОтветитьУдалитьПример из win2k сорцов:
NTSTATUS IoReportTargetDeviceChangeAsynchronous(IN PDEVICE_OBJECT PhysicalDeviceObject,
IN PVOID NotificationStructure, // always begins with a PLUGPLAY_NOTIFICATION_HEADER
IN PDEVICE_CHANGE_COMPLETE_CALLBACK Callback OPTIONAL,
IN PVOID Context OPTIONAL )
{
...
dataSize = notifyStruct->Size - FIELD_OFFSET(TARGET_DEVICE_CUSTOM_NOTIFICATION, CustomDataBuffer);
if (notifyStruct->NameBufferOffset != -1 && notifyStruct->NameBufferOffset > dataSize) <== && написанн по ошибке, явный баг
return STATUS_INVALID_DEVICE_REQUEST;
...
}
Вот такой тип уязвимости может быть банально найдет статическим анализатором кода. И судя по бинарям от винхп, он таки был найден.
А в случае MS10-046 непонятно что искать, т.к. дыра на архитектурном уровне.
А на этапе использования конечно можно детектить легко.