С нижеописанной уязвимостью я столкнулся недавно, после чего долго гуглил надеясь что эта багофича и способы ее закрытия уже известны, но не нашел ничего внятного. Теперь пытаюсь решить проблему сам, и заодно выношу её на обсуждение.

Итак, проблема заключается в небезопасных дефолтовых ACL для объектов процесса, токена и потока. В их дефолтовые ACL добавлен SID формата S-1-5-5-0-xxxxx которому разрешены некоторые действия в некоторых случаях ломающие границы системы безопасности и приводящие к раскрытию приватной информации и отказу в обслуживании.
Для демонстрации Denial of Service создайте пользователя test с паролем 1 net user test 1 /add и запустите TaskManager от этого пользователя runas /user:test taskmgr. В окне TaskManager'a вы увидите процессы своего основного пользователя (например explorer.exe) и сможете их убить. Пользователь test не имеет прав администратора, как же получается, что он может убивать процессы других пользователей? Но это ещё полбеды, теперь запустите процесс требующий повышения прав до администратора, например regedit.exe, и он будет успешно убиваться другим пользователем с пониженными правами.
Если вы думаете что это всё, то вы ошибаетесь, дальше - больше. Теперь --> скачаем <-- утилиту Process Hacker 2, извлечем из архива один только файл ProcessHacker.exe (без драйвера) и запустим под пользователем test. И что мы видим? ProcessHacker успешно показывает полную командную строку и переменные окружения всех процессов основного пользователя и других ограниченных пользователей (спасибо хоть что не администраторов), а также легко сканирует их память и показывает хранящиеся там строки. Если завершение процессов можно было как-то терпеть, то это полный ахтунг! Явки, пароли, секретные планы порабощения мира, всё может быть прочитано любой программой запущенной от отдельного пользователя, которого создали для того чтобы предотвратить такой непорядок. Обидно, да?
Теперь с помощью ProcessHacker'а ищем причины этой фигни. Сразу смотрим permissions процессов и видим странный SID формата S-1-5-5-0-xxxxx (разрешены действия Query limited information, Query information, Read memory, Terminate, Syncronize и Read permissions), лезем на вкладку Token и смотрим ACL примари токена, опять видим этот SID (разрешены Assign as primary token, Duplicate, Impersonate, Query, Query source, и Read permissions), получается что загадочный S-1-5-5-0-xxxxx может скопировать себе токен процесса, имперсонироваться и получить доступ к файлам другого пользователя. Замечательно, да? Ну и напоследок смотрим permissions потоков процесса, опять видим наш SID (разрешены Query limited information, Query information, Get context, Syncronize и Read permissions), мда, но ничего хорошего и не ожидалось.
Теперь о том, кто же такой этот S-1-5-5-0-xxxxx. Поиск S-1-5-5- в WDK дал такое описание в ntifs.h (Logon IDs) S-1-5-5-X-Y. Получается что этот SID связал с logon id с которым запущен процесс. Для проверки пробуем сделать Switch user, зайти как test и повторить предыдущие действия. Теперь система безопасности отрабатывает как надо и не дает сделать лишнего. Но это не решает проблему того, что runas страшно небезопасен!

Теперь давайте вместе попробуем ответить на извечные вопросы "кто виноват" и "что делать". Как вернуть в Windows безопасный runas, который всегда был замечательным средством изоляции програм от друг-друга?

-----
PGP key <0x1B6A24550F33E44A>

| Сообщение посчитали полезным: Vol4ok, RETOR

Предположу, что так, впринципе, оно и должно работать. Ведь для того что запустить процесс действительно под другим пользователем, Windows надо как минимум загрузить окружение того пользователя. Т.е. сделать тоже самое что и делает Switch User. А то, с какой скоростью система отрабатывает запуск через RunAs, уже понятно, что окружение другого пользователя винда не загружает..

| Сообщение посчитали полезным:

Enigma пишет:
уже понятно, что окружение другого пользователя винда не загружает..
Загружать или не загружать окружение - настраивается ключами runas, по-умолчанию оно загружается. И в Windows XP/2003 runas давал нормальную изоляцию процессов, без таких сюрпризов. Так что эта багофича новая.

-----
PGP key <0x1B6A24550F33E44A>

| Сообщение посчитали полезным:

вот только проверил, да, все работает так как ты написал, на Win 7.

Попробовал на Win Xp SP2, "runas /user:guest taskmgr", тоже самое, видно все процессы администратора, и так же их убить можно... разницы с Win 7 никакой..

| Сообщение посчитали полезным:

Enigma пишет:
Попробовал на Win Xp SP2, "runas /user:guest taskmgr", тоже самое, видно все процессы администратора, и так же их убить можно... разницы с Win 7 никакой..
Guest у вас какой-то неправильный. По-умолчанию нельзя сделать runas для guest, так как ему запрещен локальный вход в систему и отсутстует пароль (runas без пароля не делается). Если специально подкрутить настройки и поставить пароль, то таскменеджер видит все процессы (собственно винда не умеет фильтровать выдачу при перечислении процессов, и хз как её этому научить), но ничего не убивает.

-----
PGP key <0x1B6A24550F33E44A>

| Сообщение посчитали полезным:

допустим инжектимся через runas в процесс, созданный системой или админом, повышение привилегий возможно?

| Сообщение посчитали полезным:

Av0id пишет:
допустим инжектимся через runas в процесс, созданный системой или админом, повышение привилегий возможно?
Доступ на запись запрещен. Но имеется доступ на чтение, а это значит что User1 может читать память User2 - в том числе его пароли и прочую security - информацию. Это можно расценивать как уязвимость безопасности системы.
В качестве решения проблемы можно попробовать отказаться от runas, и использовать самописный аналог, который при запуске процесса вырубает Logon SID в токене (LogonUser/CreateRestrictedToken/CreateProcessAsUser). Но, подозреваю, что может отвалиться какая-то часть системного АПИ. Т.е. по-хорошему надо исследовать где и для чего этот самый SID еще используется системой.

-----
Research is my purpose

| Сообщение посчитали полезным:

сдается мне это особенность Desktop версии
есть у кого Server вариант, проверте там

| Сообщение посчитали полезным:

Доступ на запись запрещен

этого в принципе достаточно

| Сообщение посчитали полезным:

Av0id пишет:
допустим инжектимся через runas в процесс, созданный системой или админом, повышение привилегий возможно?
Возможен перескок в контекст безопасности другого пользователя через имперсонацию на токене чужого процесса, т.к. к токенам тоже разрешен излишний доступ.

Error_Log пишет:
В качестве решения проблемы можно попробовать отказаться от runas, и использовать самописный аналог, который при запуске процесса вырубает Logon SID в токене
Но explorer запускающийся от основного пользователя и запущенные им процессы по преждему будут иметь Logon SID. А кто сказал, что експлореру и всякой срани в автозагрузке должно быть разрешено чтение чего угодно?
Вообщем решение уже есть. Я написал простенький драйверок отслеживающий создание процессов и потоков и удаляющий левый SID откуда надо. На первый взгляд это работает, но толком еще не тестировал.

reversecode пишет:
есть у кого Server вариант, проверте там
Проверил на Win2008 R2 SP1 со всем патчами, работает.

-----
PGP key <0x1B6A24550F33E44A>

| Сообщение посчитали полезным:

ntldr пишет:
Я написал простенький драйверок отслеживающий создание процессов и потоков и удаляющий левый SID откуда надо.

версию под х64 ожидать можно?

| Сообщение посчитали полезным:

Простите, а что по этому поводу думает Microsoft?

| Сообщение посчитали полезным:

Gideon Vi пишет:
версию под х64 ожидать можно?
Сегодня-завтра будет выложена подписанная версия с исходниками.

Wyfinger пишет:
Простите, а что по этому поводу думает Microsoft?
Знать бы как у них спросить...

-----
PGP key <0x1B6A24550F33E44A>

| Сообщение посчитали полезным: Gideon Vi

Выкладываю драйвер решающий проблему.

--> psstrict.zip <--

-----
PGP key <0x1B6A24550F33E44A>

| Сообщение посчитали полезным:

ntldr
Спросил здесь.

Надеюсь заметят, подождем ответа.

UPD:
Один из ответов
Ilya Tumanov (MSFT)
Даже если все так, то сценарий сам по себе сомнителен. Ведь пользователь А который использовал runas для запуска от имени пользователя Б и так может убивать процессы пользователя А, видеть их командные строки и т.п. Т.е. если "за рулем" "злодей" без присмотра то ему никакие runas не потребуются, все и так доступно. То же касается "злодейского приложения" который под любым эккаунтом будет иметь слишком много прав.

Кстати, runas скорее является средством для запуска от лица другого пользователя (например с целью получения прав которых у текущего пользователя нет), а не средством изоляции (понижения доступа).

Так же рекомендую посмотреть тут: http://technet.microsoft.com/en-us/library/cc722487.aspx, пункты #1, #3.

| Сообщение посчитали полезным:

Enigma пишет:
Попробовал на Win Xp SP2, "runas /user:guest taskmgr", тоже самое, видно все процессы администратора, и так же их убить можно... разницы с Win 7 никакой..
Так там же пишется при создании учётной записи делать полный доступ или огранниченный,если выбираешь огранниченный то нефига ты там неувидешь...

-----
Чтобы правильно задать вопрос, нужно знать большую часть ответа. Р.Шекли.

| Сообщение посчитали полезным:

Итак, достигнутые результаты:
Удалось украсть токен из уязвимого процесса, имперсонироваться на нем и получить полный доступ к файлам другого пользователя (на чтение и на запись).
Удалось украсть Elevated токен из процесса администратора, удалось имперсонироваться на нем но непонятно что делать дальше, по такому токену винда никуда доступа не дает.
Не удалось сделать CreateProcessAsUser, потому что нужны привилегии SE_ASSIGNPRIMARYTOKEN_NAME и SE_INCREASE_QUOTA_NAME, которых у нас нет.

В аттаче прилагаю эксплоит демонстрирующий доступ к файлам других пользователей.

___ - exploit.zip

-----
PGP key <0x1B6A24550F33E44A>

| Сообщение посчитали полезным:

Wyfinger пишет:
Один из ответовIlya Tumanov (MSFT)Даже если все так, то сценарий сам по себе сомнителен. Ведь пользователь А который использовал runas для запуска от имени пользователя Б и так может убивать процессы пользователя А, видеть их командные строки и т.п. Т.е. если "за рулем" "злодей" без присмотра то ему никакие runas не потребуются, все и так доступно. То же касается "злодейского приложения" который под любым эккаунтом будет иметь слишком много прав.
Сейчас уже не эпоха Windows 9x, где любое приложение могло делать что заблагорассудится. Windows начиная с NT4 позиционируется как многопользовательская ОС имеющая все нужные средства разграничения доступа. А runas может использоваться (и успешно использовался в XP/2003) для изоляции небезопасных сетевых приложений, таких как браузер, что позволяло защититься от большинства атак.
То что я вижу в Windows 7 - это существенная брешь в безопасности системы. Но полагаю что это никогда не будет исправлено, баг объявят фичей, скажут что так надо и забудут.


Похоже что в топике на microsoft.com наметилось непонимание сути уязвимости. Объясняю подробней: допустим у нас в системе есть небезопасное приложение, например браузер, содержащее уязвимости, которое тем не менее нам нужно использовать. Для запуска этого приложения создается аккаунт ограниченного пользователя и запуск производится с помощью runas. Этим мы желаем добиться изоляции уязвимого приложения от остальной системы, чтобы любая атака на него не вышла за пределы ограниченного пользователя. В Windows XP/2003 всё так и работало, а в Windows 7 благодаря вышеописанной уязвимости атакующий может получить доступ к данным основного пользователя и других ограниченных пользователей, от имени которых через runas могут быть запущены другие изолированные приложения, чего не должно быть.

-----
PGP key <0x1B6A24550F33E44A>

| Сообщение посчитали полезным: Jupiter

ntldr пишет:
Выкладываю драйвер решающий проблему.

привяжи его к какой-нибудь софтине, плз. Так ставить не удобно.

| Сообщение посчитали полезным:

Разговарить с манагерами и быдлоадминами на technet бесполезно. Они ничего не решают.

Вам сюда secure@microsoft.com
Инструкции здесь http://technet.microsoft.com/ru-ru/security/ff852094.aspx

Максимально подробно изложить проблему, приложить PoC, все писать на английском. Если нет ответа в течение суток продублировать сообщение.

| Сообщение посчитали полезным:

Забавно

| Сообщение посчитали полезным:

Ну автор этого уютного бложика не первый раз смотрит на форум и участников косо https://ssl.exelab.ru/f/action=vthread&forum=7&topic=18520 Непонятно только, чего он продолжает сюда ходить или почему не может прямо здесь аргументированно отстаивать свою точку зрения.

| Сообщение посчитали полезным:

C/Kashmir пишет:
Забавно
Раз забавно, почему бы автору не ответить здесь? Ну так и быть, отвечу ему здесь: Уважаемый автор, в моем посте не было ни слова ни про IE ни про Integrity Level, потому что это ни в малейшей мере к делу не относится. Речь шла о небезопасном runas. Ваше право считать что доступ одного ограниченного пользователя к данным другого, когда это не разрешено явно, - это не уязвимость. Но у меня другое мнение.
По теме: ок, напишу на secure@microsoft.com, и нет смысла дальше толочь воду в ступе. Все что надо я для себя выяснил, воркараунд сделал, а дальше пусть объявляют это хоть багом хоть фичей.

-----
PGP key <0x1B6A24550F33E44A>

| Сообщение посчитали полезным:

а задать программе Integrity Level нельзя?

| Сообщение посчитали полезным:

xetis пишет:
а задать программе Integrity Level нельзя?
Можно. icacls program.exe /setintegritylevel Low, но это не предотвращает чтения папки "мои документы". Integrity Levels это полезный и удобный механизм, но выполняет другую задачу нежели runas.
Установка Low Integrity Level на процессы запускаемые из-под runas частично решает проблему, но только частично, потому что процессы с Low Integrity Level могут получить доступ к данным друг друга, хотя они запущены от разных пользователей.
И процесс с Low Integrity Level отлично убивает explorer, можете сами убедиться.

-----
PGP key <0x1B6A24550F33E44A>

| Сообщение посчитали полезным:

Давайте не будем переходить на личности и меряться у кого ум длиннее. Топик о конкретной уязвимости и хотелось бы обсуждать конкретную уязвимость, а не разводить очередной срач.
Прошу модераторов почистить топик и надеюсь в дальнейшем на конструктивные посты.

З.Ы. свои неполиткорректные высказывания я уже подчистил.

-----
PGP key <0x1B6A24550F33E44A>

| Сообщение посчитали полезным:

Ведь пользователь А который использовал runas для запуска от имени пользователя Б и так может убивать процессы пользователя А, видеть их командные строки и т.п. Т.е. если "за рулем" "злодей" без присмотра то ему никакие runas не потребуются, все и так доступно

Какой-то неадекватный коммент. Говорится же именно про то, что "злодей" - процесс, запущенный от имени пользователя Б, который должен быть ограничен в правах. Пользователь А и так имеет/может иметь суперпривилегии, и именно их нужно ограничить за счёт рестрикт токена при runas. Никто не в курсе, у мелкомягких есть что-то типа книги жалоб на таких вот консультантов?

Кажется, ntldr говорил, что это объявят фишкой? Нате, пожалуйста:
Я подозреваю что это было сделано вполне намерено. Если пользователь А запустил процесс под пользователям Б то логично ожидать что данный процесс имеет доступ к ресурсам пользователя А который, собственно, и запустил процесс. Скорее всего в ХП это не работало и поведение было изменено.

Если бы все было так просто то наверное никто не выпускал бы специальные "песочницы", нет?
Ну это вообще агонь. Песочницы выпускают не только (и иногда даже не столько) для рестрикта, сколько для анализа и обнаружения, какие имеено зловредные действия выполняет тот или иной софт. Или я что-то пропустил?

-----
Stuck to the plan, always think that we would stand up, never ran.

| Сообщение посчитали полезным:

Не надо ни на кого жаловаться. В Microsoft работает много людей, и все не обязаны понимать работу системы безопасности и сходу въезжать в суть проблемы. Напишем официально на secure@microsoft.com, а там посмотрим.

-----
PGP key <0x1B6A24550F33E44A>

| Сообщение посчитали полезным:

А на форуме мелкомягких Илюха продолжает жечь:
Кстати, тут тоже интересный вопрос: кнопочка Х нажимает от пользователя или админа? Как на счет меню "выход" в самом окне? А комбинация ALT-F4 чья?

Или я не могу понять его глубоких мыслей, или мои представления про Windows в корне неправильны. Товарищи, поправьте меня. При нажатии на кнопочку Х или выборе меню Выхода/нажатии ALT-F4 в окне приложения окно этого приложения получает сообщение WM_CLOSE, управление передаётся каллбэку этого окна (оконной процедуре обработки сообщений) и, как обычно происходит, процесс того же блокнота сам себя завершает посредством вызова системного сервиса ZwTerminateProcess, при этом вызов PsGetCurrentProcessId при, например, перехвате сервиса, это ясно даёт понять. Что ж тут непонятно?

Допустим рассеяный админ делая что то на компьютере пользователя открыл блокнот и забыл его закрыть. Как минимум пользователь имеет неубиваемое окно. Как максимум злобный пользователь имеет неубиваемое окно которое выполняется с правами админа и позволяет читать, записывать и менять любые файлы к которым админ (не обязательно локальный) имеет доступ.

Опа! Если раньше он хоть глюк в семёрке называл фичей, то сейчас он runas XP называет глюком, да и более того - приводит пример сценария, которого не было при нормальной работе в ХР. Попробуйте в ХР запустить под учёткой пользователя калькулятор от имени админа. Что он у вас, не закроется потом?

Туманов, ты звезда!

-----
Stuck to the plan, always think that we would stand up, never ran.

| Сообщение посчитали полезным: ==DJ==[ZLO]

Не знаю причем тут какие-то кнопочки, это всё неконкретная демагогия.
Мой тезис: если пользователь A имеет доступ к данным пользователя B, при этом пользователь A не является администратором и разрешение на доступ к данным пользователя B не было дано явно - то это уязвимость. С тезисом согласны? Нет - приводите аргументы.
Теперь разбор нашей ситуации по пунктам:
1 - Пользователь A имеет доступ к данным пользователя B (его домашней директории на чтение и запись и памяти его процессов на чтение).
2 - Пользователь A не является администратором.
3 - Ни пользователь B ни администратор не разрешали пользователю A такой доступ. Использование runas не подразумевает что мы что-либо разрешаем пользователю A, мы просто хотим запустить приложение от пользователя A в его контексте безопасности.
4 - Из пунктов 1-3 делаем вывод что уязвимость налицо. Неважно что такое поведение может быть следствием какой-либо фичи или архитектурной особенности системы, уязвимость от этого не перестанет быть уязвимостью.
Не согласны - приводите аргументы в тезисном формате, без не относящихся к делу предположений и без аналогий. Т.е. "я не согласен с тем-то, потому что...". Именно так должен происходить конструктивный диалог, а не демагогия и словоблудие.

Что из вышесказанного могут попытаться опровергнуть несогласные? Во-первых можно не согласиться с определением уязвимости, т.е. признать что явно не разрешенный доступ пользователя A к данным пользователя B это нормально. Во-вторых можно попытаться доказать что запуск через runas должен давать какие-то дополнительные права пользователю A, если так - то прошу ссылку на сайт MS где документировано такое поведение.

-----
PGP key <0x1B6A24550F33E44A>

| Сообщение посчитали полезным: