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

Итак, проблема заключается в небезопасных дефолтовых 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

Ктонибудь использует DropMyRights или PsExec для таких же целей защит? DropMyRights вообще на 7 работает? Я в сандбоксе подобие DropMyRights использую , хз что лучше и на что перейти)

Да Да , а Gideon Vi гадает на кофейной гуще) выбор не очевиден) даже зная перевод и функционал))) .. Пилите, Шура, пилите ..

-----
RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube

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

mak пишет:
DropMyRights вообще на 7 работает?

да

mak пишет:
Я в сандбоксе подобие DropMyRights использую , хз что лучше и на что перейти)

sandboxie - это песочница. DropMyRights просто сбрасывает права. Выбор очевиден, не?

а Gideon Vi гадает на кофейной гуще)

хм?

выбор не очевиден) даже зная перевод и функционал)))



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

ARCHANGEL пишет:
Что он у вас, не закроется потом?
Естественно закроется. Как без runas админить компы бухов? Туманов походу 12 летний мудак, который комп видел только у родителей в комнате.

-----
Yann Tiersen best and do not fuck

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

Выкладываю дрова обёрнутые в инсталлер, само собой вместе с сорсами.

--> psstrict_setup.exe <--
--> psstrict_src.zip <--

-----
PGP key <0x1B6A24550F33E44A>

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

А зачем тут дрова вобще? Если у юзверя есть возможность запускать драйвера, то это какбы ложит большой толстый болт на всю безопасность системы. О какихто уязвимостях в таком случае вобще говорить не стоит.

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

ну и как это понимать?

то есть, если я могу установить драйвер для видеокарты, это делает бесполезной всю защиту?

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

SegFault, Вам бы перечитать посты ntldr. Раза два перечитать.

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

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

-----
Yann Tiersen best and do not fuck

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

ntldr, есть bsod. Инфа в личке

PE_Kill пишет:
Это его первый пост. Неужто Туманов таки зарегался, чтобы ляпнуть такую херню?

туманов - это тот словоблуд с бложика?

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

SegFault - дрова ставит администратор дабы оградить пользователя A от пользователя B
прав на установку дров естественно никто никому не дает
с установленными дровами позователь А лишается фичевой возможности влиять на В

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

Rockphorr
пасиба за разъяснение, я просто не читал предыдущие постенги
теперь понятно

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

Gideon Vi пишет:
ntldr, есть bsod. Инфа в личке
Fixed. Исправленная версия доступна по старым ссылкам. При установке новой версии старую можно не удалять, она сама корректно обновиться.

-----
PGP key <0x1B6A24550F33E44A>

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

Дальнейшее изучение уязвимости выявило что всё хуже, чем изначально предполагалось. Любой процесс запущенный через runas может загрузить во все процессы Logon сессии свою dll через SetWindowsHookEx.
В XP/2003 эта уязвимость тоже отсутствует. Моя заплатка эту дыру не закрывает, сейчас думаю как лучше это пофиксить.

Ну и на десерт: уязвимость появилась ещё в Vista и сохраняется до сих пор, а значит 99% что это не баг - это такая фича, спускающая в унитаз всю стройность и прозрачность системы безопасности.

-----
PGP key <0x1B6A24550F33E44A>

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

ну т.е. грубо говоря можно стырить пароли? инжект имеется в виду примерно такой?



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

Да. Можно стырить пароли, можно получить полный доступ к данным других пользователей, можно запускать процессы от их имени.
И главное - не понятно что с этим делать. В XP и 7 стоят одинаковые права для Logon SID на объекты Window Station и Desktop (разрешен полный доступ), но в XP хуки не выходят за пределы контекста пользователя, как и должно быть, а в семерке без лишних слов происходит инжект в процессы всех пользователей имеющих тот-же Logon SID и одинаковый Integrity Level с инжектором. Понижать Integrity Level не выход, т.к. это мешает записи в пользовательский профиль (хотелось бы чтобы приложения работали изолированно, но более-менее полноценно), к тому-же низкий Integrity Level не мешает инжектить в другие приложения с низким Integrity Level, хоть они и запущены от других пользователей. Убирать акцесс "Hook Control" с декстопа - не выход, т.к. перестают запускаться приложения использующие MSVC рантайм.


UP: Нормально починить runas и вернуть как было в XP не получается, остается один вариант - писать свой runas который будет сам назначать процессам разные Logon SID.

-----
PGP key <0x1B6A24550F33E44A>

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

А logon sid юзеров, залогиненных "полностью", через switch user, а не runas, одинаков? То есть, это всё еще бага runas или, создавая хук, можно загрузить себя вообще всем твоего же integrity level?

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

tomac пишет:
А logon sid юзеров, залогиненных "полностью", через switch user, а не runas, одинаков?
Нет, при запуске через switch user создается другой LogonSID.

tomac пишет:
То есть, это всё еще бага runas
Это бага проявляющаяся при использовании runas. А лежит она глубже в системе. runas использует функцию CreateProcessWithLogonW, которая передает запрос сервису Secondary Logon, а этот сервис уже загружает профили, назначает LogonSID, управляет акцессами десктопов, и.т.д. Уязвимость касается всего, что использует CreateProcessWithLogonW.
Единственное решение без кривожопых хаков - написать свой аналог сервиса "Secondary Logon" и свой runas который будет с ним взаимодействовать, чем я собственно сейчас и занимаюсь.

-----
PGP key <0x1B6A24550F33E44A>

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

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

Может быть быстрее заметят если засветить сею поделку на securitylab

-----
Gutta cavat lapidem. Feci, quod potui. Faciant meliora potentes

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

В процессе написания своего runas заметил, что у запущенных через него процессов очень сильно тормозят окна открытия и сохранения файлов. В процессе гугления наткнулся на --> Link <--.

Я уже создавал ранее тему "Тормоза" в Windows Vista. В результате пришел к выводу, что создаваемый процесс не будет под Windows Vista (в XP нормально работает) нормально работать, если LogonSID токена, с помощью которого создается процесс, не соответсвует LogonSID процесса explorer.exe в сессии, в которой запускается процесс. И никакие примочки в виде изменения DACL для WindowStation, Desktop, \Sessions\(номер сессии)\BaseNamedObjects для создаваемого процесса, если его Logon SID не равен експлореровскому, не помагают.
Ну пиздец. Нет слов, одни маты. Какой мудак это придумал?

Еще цитата из другого топика на rsdn:
Нуну. Берем висту. Запускаем через runas под отдельным юзером консоль. Идем в каталог студии, tools запускаем spyxx.exe. Смотрим список длл во всех GUI процессах на том же десктопе с таким же integrity level — во все процессы загрузилась spyhk55.dll. Вывод №1- подсистема безопасности висты (на ХР с этим было все ок) ваще никак не обеспечивает защиту процессов работающих под разными пользовательскими аккаунтами если они работают на одном и том же десктопе
Получается что проблема старая, не мною первым замечена, но тем не менее до сих пор ничего не исправлено. Видимо в Microsoft считают что так надо.

-----
PGP key <0x1B6A24550F33E44A>

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

DenCoder пишет:
ntldr, а сообщи в европейскую комиссию, пусть m$ ещё штрафанут ))
Хватит всякий бред писать

На самом деле, было бы неплохо услышать официальный комментарий ответственного лица MS по поводу данной проблемы, и есть ли нормальный способ, как с этим можно бороться (может велосипед уже изобретен?).

Все-таки, кто-то писал письмо в MS ?

-----
Research is my purpose

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

Error_Log пишет:
Хватит всякий бред писать
http://www.livejournal.ru/themes/id/5277
Ну не еврокомиссия, евросоюз - очепятка )

Я поясню мотивацию. Сейчас m$ уверена в своей непогрешимости и открывает всем свои исходные коды, чтобы убедить что их системы действительно безопасны. Так навести тех, кто смотрит исходники, на фичу-баг в безопасности, которую нашёл ntldr. Как отнесутся к такой фиче системные администраторы в компаниях и их внутренняя служба безопасности? По-моему, очевидно, что это просчёт m$.

Error_Log пишет:
есть ли нормальный способ, как с этим можно бороться (может велосипед уже изобретен?).
Что, за 2.5 недели никто не смог найти? Из того, что нашёл ntldr, можно сделать вывод, что оплошность воистину трудноустранима.

Error_Log пишет:
На самом деле, было бы неплохо услышать официальный комментарий ответственного лица MS по поводу данной проблемы
Да, это действительно интересно. Но как будто представители не читают? Что они, боятся здесь вирус подхватить своим осликом? Как --> здесь <-- испугался вирусов модератор технета и партнёр m$ Игорь Лейко, поправив пост wyfinger? Уж сами представители всё знают и ничего не боятся. Во-первых, им самим трудно найти решение, ведь в эволюции мастдайки изменился подход. Во-вторых, всё что в новостях - только вершина айсберга, у них должно быть сейчас полно других проблем...

Итог:
И что? Если ЕС будет в курсе проблемы, у m$ будет выбор: представить этот баг как фичей и объяснить как пользоваться другими возможностями безопасности, либо всё же исправить свой баг.

-----
IZ.RU

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

Эй, осадите коней пожалуйста. Я ничего не имею против Microsoft и меньше всего хочу чтобы моё имя фигурировало рядом с политикой. Это просто неопасная уявзимость, которую нужно исправить, либо (если её официально признают фичей) сделать рабочий воркараунд. Вот и всё. Официального ответа ещё не было, ждем.

-----
PGP key <0x1B6A24550F33E44A>

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

А зачем её закрывать м$ ? Они знают про неё 100% и используют во благо себе (ИМХО) Они ещё заплатят пару "мультиков*10" $ и все будет переносить процесс исправления. Для стационаров решение очевидно , а вот для крупногобаритных компаний у админов трабл. Дочерний софт я думаю всем в помощь.

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