Google против Microsoft; команда Google Research сделала еще две уязвимости Windows 7/8 публичными

Война Google против Microsoft накаляется, так как Google раскрывает еще две уязвимости Windows 7 и Windows 8.

Команда Google Research в четверг опубликовала две неустраненные уязвимости Windows в открытом доступе после истечения установленного Google Project Zero 90-дневного срока ожидания перед раскрытием деталей ошибок.

Microsoft, которая не очень хорошо относится к таким публичным раскрытиям, заявила, что исправит одну из двух уязвимостей в своем предстоящем бюллетене безопасности Patch Tuesday в феврале. Вторая уязвимость, похоже, не представляет собой серьезной проблемы безопасности.

Читатели могут помнить, что команда Google Research сделала уязвимость повышения привилегий в Windows 7 публичной после истечения 90-дневного срока ожидания. Раскрытие Google 29 декабря возобновило дебаты о раскрытии среди энтузиастов безопасности и вызвало недовольство и публичные заявления от обеих компаний.

Microsoft хочет, чтобы Google следовал программе координированного раскрытия уязвимостей и просила Google удержать раскрытие уязвимости до январских бюллетеней безопасности, которые были выпущены на этой неделе. Google, с другой стороны, полагается на свой установленный 90-дневный мораторий, поэтому отказался и продолжил раскрытие.

Крис Бетц из Microsoft заявил: «Хотя следование графику раскрытия Google кажется правильным, это решение больше похоже на «поймали на слове», и в результате могут пострадать клиенты. То, что правильно для Google, не всегда правильно для клиентов. Мы призываем Google сделать защиту клиентов нашей общей первоочередной целью.»

Война между технологическими гигантами далеко не окончена, так как команда Google Research сделала еще две уязвимости Windows публичными. Обе уязвимости представлены ниже:

Проблема № 127, сообщенная Microsoft 17 октября 2013 года, сделана публичной 15 января 2014 года

Платформа: Windows 7 32/64 бит, Windows 8+ не уязвим Класс: Обход безопасности В системном вызове NtPowerInformation выполняется проверка, что вызывающий является администратором, прежде чем выполнять некоторые специфические функции управления питанием. Проверка выполняется в функции PopUserIsAdmin. Грубая реализация выглядит так: BOOLEAN PopUserIsAdmin() { SECURITY_SUBJECT_CONTEXT ctx; SeCaptureSecurityContext(&ctx); return SeTokenIsAdmin(SeQuerySubjectContextToken(&ctx)); } В Windows 7 эта проверка может быть обойдена, потому что функция SeTokenIsAdmin не учитывает уровень имитации токена, и остальной код также не учитывает это. Поэтому вы можете имитировать токен администратора как обычный пользователь (через связанный токен или похищение системного токена) и вызывать защищенные функции. В Windows 8+ метод SeTokenIsAdmin был изменен, чтобы проверять уровень имитации, поэтому он не уязвим. Неясно, имеет ли это серьезное влияние на безопасность или нет, поэтому оно раскрывается как есть. Некоторые функции также проверяются с помощью проверки привилегий, однако контекст субъекта захватывается отдельно, поэтому существует окно TOCTOU между проверками, которое может быть использовано в атаке. Для целей PoC я выбрал использовать функцию 45 «PopRequestPowerListInfo» (которая не требует никаких специальных трюков). Также эта функция имеет теоретическую уязвимость переполнения целого числа в зависимости от того, насколько вы можете увеличить размер PopPowerRequestObjectCount. Прилагается простой PoC, который демонстрирует проблему для выполнения на Windows 7. Чтобы воспроизвести, выполните следующие шаги. 1) Убедитесь, что вы работаете как администратор с разделенным токеном, это связано с тем, что PoC использует связанный токен для получения токена администратора. Для обычного пользователя вы можете просто захватить токен от службы.

2. Выполните PoC, он должен выполнить вызовы, один без имитации и один с. Ожидаемый результат: Оба вызова должны вернуть STATUS_ACCESS_DENIED (0xC0000022) Наблюдаемый результат: Первая проверка завершается неудачей с STATUS_ACCESS_DENIED, в то время как вторая завершается успешно с STATUS_SUCCESS. PoC для загрузки => 1 2

Проблема № 128, сообщенная Microsoft 17 октября 2013 года, сделана публичной 15 января 2014 года

Платформа: Windows 7, 8.1 Update 32/64 бит Класс: Обход безопасности/Раскрытие информации Функция CryptProtectMemory позволяет приложению шифровать память для одного из трех сценариев: процесс, сеанс входа и компьютер. При использовании параметра сеанса входа (флаг CRYPTPROTECTMEMORY_SAME_LOGON) ключ шифрования генерируется на основе идентификатора сеанса входа, это для обмена памятью между процессами, работающими в одном и том же сеансе входа. Поскольку это также может использоваться для отправки данных от одного процесса к другому, оно поддерживает извлечение идентификатора сеанса входа из токена имитации. Проблема в том, что реализация в CNG.sys не проверяет уровень имитации токена при захвате идентификатора сеанса входа (с использованием SeQueryAuthenticationIdToken), поэтому обычный пользователь может имитировать на уровне идентификации и расшифровывать или шифровать данные для этого сеанса входа. Это может быть проблемой, если существует служба, уязвимая к атаке с использованием именованной трубы или хранящей зашифрованные данные в разделе общей памяти, доступной для чтения. Это поведение, конечно, может быть задумано, однако, не будучи частью дизайна, трудно сказать. Документация утверждает, что пользователь должен имитировать клиента, что я понимаю как возможность действовать от имени клиента, а не идентифицироваться как клиент. Прилагается простой PoC, который демонстрирует проблему. Чтобы воспроизвести, выполните следующие шаги. 1) Выполните Poc_CNGLogonSessionImpersonation.exe из командной строки

2. Программа должна напечатать «Шифрование не совпадает», чтобы указать, что два шифрования одних и тех же данных не совпали, что подразумевает, что ключ был разным между ними. Ожидаемый результат: Оба вызова должны вернуть одинаковые зашифрованные данные, или второй вызов должен завершиться неудачей Наблюдаемый результат: Оба вызова завершаются успешно и возвращают разные зашифрованные данные PoC для загрузки => Zip File

Microsoft исправит только одну из уязвимостей в своем Patch Tuesday в феврале, который, по его словам, не является угрозой безопасности. Оба Microsoft и Google заявили, что у них нет доказательств того, что какие-либо из трех публично раскрытых уязвимостей были использованы в дикой природе.