MS рассказывает об истоках WMF-уязвимости
dl // 16.01.06 17:25
Всей истории уже сильно больше 15 лет.
[Не забывайте при копировании материала указывать полный адрес источника: //bugtraq.ru/rsn/archive/2006/01/09.html]
Во времена кооперативной многозадачности функциональность SetAbortProc и callback-функций была необходимым компонентом для обеспечения возможности прерывания печати - даже до появления метафайлов. В районе 90-го года поддержка wmf была добавлена в Windows 3.0, а функциональность SetAbortProc подправлена для того, чтобы она понимала, когда вызвана из метафайла. В те времена отношение к безопасности было совершенно другим, и метафайлы воспринимались как источник, заслуживающий полного доверия от ОС.
Потенциальная опасность записей типа META_ESCAPE, приводящих к вызову SetAbortProc, была замечена чуть позже, и ряд приложений (включая IE) стал их просто игнорировать, так что простое подсовывание web-пользователю wmf-файла не приведет ни к каким проблемам. Однако осталась возможность косвенного их срабатывания - например, с помощью Windows Picture and Fax Viewer (тот самый shimgvw.dll), который конвертирует "чистый" WMF в EMF, честно обрабатывая ту самую злосчастную запись. Собственно говоря, все существующие схемы атаки на данную уязвимости используют тег IFRAME, передающий этот файл оболочке, в которой просмотрщиком wmf-файлов по умолчанию является как раз Windows Picture and Fax Viewer.
Что касается недавнего обвинения в преднамеренности данной ошибки, возникающей только при вполне определенном некорректном значении поля с размером записи, то оба утверждения неверны. Уязвимость может сработать и при корректном, и при некорректном значении. Если кому-то удалось заставить работать ее только при некорректном значении, то только потому, что запись, приводящая к вызову SetAbortProc, была последней записью в метафайле, в то время как механизм использования уязвимости заключается в регистрации callback-функции, которая будет вызвана при обработке следующей записи метафайла.
