четверг, 29 мая 2008 г.

Vista UAC: почему не выключать.

Да-да, я все же решил наступить на любимую мозоль IT сообщества. Такого количества нареканий не вызывала на моей памяти ни одна особенность ОС. Эпитеты даются от "великолепный" "ублюдочный" до "выключить его к чертовой бабушке". Самое проблематичное, что объяснить, как это работает, и каким образом Вас защищает без погружения в пучины океана сложные для любого непрограммиста рассуждения почти невозможно. Зато "неудобства" видны сразу, потому что как только мы пытаемся запустить приложение, которое написано без учета UAC, устаревшее приложение, некачественно написанное приложение или произвести административное действие - вот оно - UAC тут как тут. Однако сегодня можно привести понятный всем пример. Хотя и не удержусь, чтобы не проехаться по "неудобствам"

Если говорить о программах, то здесь все ясно - на самом деле нужно обращаться в поддержку программы и требовать версию, которая поддерживает UAC. В некоторых случаях, конечно, придется терпеть, потому что замены нет и не будет. Но таких случаев не так чтобы много.

Что касается административных действий... Я, как системный администратор даже не работе не так часто встречаюсь с необходимостью оных. Несколько инструментов у меня запущены весь день, остальные запускаются не так чтобы часто. Потому мне лично UAC просто помогает: нет необходимости производить дополнительные манипуляции, чтобы запустить нужные утилиты под учетной записью администратора (да-да, я работаю под обычным пользователем) - да здравствует легко и удобно применяемый принцип наименьших привилегий!!! =)

Однако вернемся, наконец, к тому, с чего я начал: сегодня мы можем показать наглядно, как нас может защитить UAC. Собственно, мне даже показывать ничего не придется, достаточно привести ссылку на статью в PCWorld, которая описывает результаты некоего теста, проведенного вполне уважаемой организацией - AVTest.org.  В этом тесте вполне очевидно проявила себя состоятельность UAC (несмотря на то, что цель теста была совершенно иной - испытание anti rootkit средств). Мало того, что встать на Vista смогли только 6 руткитов из 30 (что, само по себе ни о чем не говорит - ну не выпустили пока достаточного количества руткитов для Vista - еще успеют), так эти шесть вредоносных комплексов еще и смогли быть установленными на Vista только после выключения UAC. Отсюда вывод - выключите UAC - снизите защиту. Думаю, что хоть теперь это достаточно очевидно =)

Если же кто-то заинтересуется непосредственно тем, которое из антизловредных программ лучше вправляется с руткитами - добро пожаловать для прочтения самого отчета.

37 комментариев:

osr комментирует...

Остается только добавить, что, используя Microsoft Application Compatibility Tollkit 5.0, можно преодолеть многие проблемы несовместимости приложений, в том числе и некорректную работу при включенном UAC. Подробнее о ACT 5.0 см.

http://technet.microsoft.com/en-us/windowsvista/aa905102.aspx

KomatoZo комментирует...

Согласен, Олег =)
Хотя мне редко приходится пользоваться.

Проничкин комментирует...

Vista UAC — почему не включать: http://pronichkin.com/Lists/Posts/Post.aspx?ID=73

=)

KomatoZo комментирует...

Так а где против-то? =)
Я вижу сплошные за. Даже те два варианта, которые исходно вроде как обозначены отрицательными - а просто подумать только, что будет, если UAC не будет? =)
По поводу второго варианта, кстати, насколько я понимаю, получить доступ к процессу, который запущен с повышенными привилегиями, процесс, запущенный с обычными не сможет. Integrity Level и прочие заумные штучки =)

Проничкин комментирует...

1. Если UAC не будет — не произойдёт никакого повышения прав. Ни желаемого, ни нежелательного. Хочешь произвести административное действие — изволь заблокировать свой сеанс, нажать ctrl-alt-delete и открыть новый.

Ещё раз — я ни в коем случае НЕ говорю, что надо сидеть под админом с выключенным UAC. Сидеть надо под пользователем с выключенным UAC! А под админом заходить изредка для выполнения конкретных задач. И причём у административной учётной записи UAC должен быть включен!

2. По поводу того, может ли один процесс получить доступ ко второму. Посмотри в моей статье ссылку на пост Алексея Пахунова (not-a-kernel guy). Там в комментариях умные ребята программисты интересно развивают эту тему. Говорят, что такой доступ запросто осуществим — таков уж механизм работы Windows Manager.

KomatoZo комментирует...

1) Паранойя чистой воды. =)Пользователь не должен иметь админских прав. И иметь включенной опцию "UAC: Behavior of the elevation pro,pt for standard users" выставленной в "Automatically deny elevation request"
2) Почитаю, спасибо. Хотя заранее говорю, что спорить не буду - не мое поле. Так глубоко я не зарывался еще =)

проничкин комментирует...

Угу, именно «Automatically deny». Я бы не сказал, чтобы это была совсем чрезмерная параноя. Всё-таки, в контролируемой среде у пользователя вообще не должно возникать необходимости повышения прав. Если такие потребности всё-таки возникают — то это уже сингнал для тех, кто отвечает за безопасность.

По крайней мере, разработчики «Windows Vista Security Guide» со мной солидарны. Причём как в случае «зверских» настроек SSLF, так и в значительно более мягкой среде EC.

Насчёт спора на чужом поле — согласен. Я сам в этом не особо разбираюсь, но не могу не поверить на слово разработчику из команды ядра Windows.

KomatoZo комментирует...

Тогда я тебя не до конца понял - ты просто сказал "отключить". Я и подумал, грешным делом, что совсем отключить ;)

Анонимный комментирует...

Подробно о UAC можно прочитать тут http://blogs.technet.com/abeshkov/archive/2008/05/12/3053967.aspx

проничкин комментирует...

Ну я согласен, что в каментах такую тему сложно обсуждать, называя вещи своими именами. Поэтому и написал однажды длиннющую статью =)

KomatoZo комментирует...

To Анонимный: Спасибо. =)
To Проничкин: ну у меня цель была только показать, что теперь есть понятный всем повод не отключать UAC =)
А тут такая дискуссия развернулась. Прям становлюсь популярным =)

проничкин комментирует...

да я спорю разве =)

Оно понятно, что если пользователь по каким-то причинам сидит под админом — то лучше делать это с UAC, чем без него. И твой пост про «понятный способ не выключать UAC» относится именно к такой ситуации.

Я-то говорю о другой ситуации. Когда пользователь работает с ограниченными правами — то без UAC оно ещё лучше, чем с ним. Иными словами, смысл моего комментария был другой: UAC — хорошая штука, но не всегда и не везде.

Кстати, пост в блоге Бешкова, на который только что дали ссылку, — это была как раз та «последняя капля», которая и заставила меня разродиться своей заметкой =).

проничкин комментирует...

поправка — не способ, а повод =)

KomatoZo комментирует...

Ммм... Возможно. Просто я смотрю со своей колокольни. Так как я админ, то мне как раз быстрый способ повышать привилегии необходим. Иначе полдня буду переключаться из одной учетки в другую - не айс, сам понимаешь. Кстати, способ, который продемонстрировали программеры по поводу хака сессии с повышенными привилегиями будет работать и в предложенном тобой сценарии "выйди/войди" =)

проничкин комментирует...

Насколько я понимаю, именно в случае «войди-выйди» хук как раз работать не будет, потому что приложения не могут вылезти за пределы своей сессии. Собственно, именно это было причиной изоляции служб в нулевом сеансе, которую придумали в висте и сервере 2008. Хотя признаю, что если нужна полная уверенность — потребуются дополнительные изыскания в этом вопросе. Точной гарантии у меня сейчас нет, просто логика =).

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

ЗЫ. Кстати, эксперименты показали, что с помощью runas + скрипта можно обойти даже «automatically deny» ;)

KomatoZo комментирует...

Да, про изоляцию сессии я не подумал. Есть смысл.
А про то, что можно обойти. Да, можно. Так ведь пойнт не в том, чтобы защититься от того, что уже стоит на твоем компьютере или от заведомо деструктивных действий пользователя. Оно защищает от того, что еще не проникло. Я по этому поводу всегда цитирую http://www.microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx
UAC предназначен для того, чтобы уменьшить вероятность срабатывания пунктов 1 и 2, по моему.

KomatoZo комментирует...

Обрезалось почему-то...
http://www.microsoft.com/_
technet/archive/community/_
columns/security/essays/_
10imlaws.mspx
Подчеркивания убрать или просто найти "10 Immutable Laws of Security"
=)

проничкин комментирует...

Ну да. Поэтому я и писал, что UAC — не средство защиты как таковое. Если уж зараза проникла на компьютер — UAC может принести больше вреда, чем пользы. Собственно, об этом я и писал у себя, когда объяснял, почему в среде с высокими требованиями к безопасности не стоит полагаться на UAC.

И понятно, что при желании обойти можно всё. Можно, к примеру, отключить антивирус — однако это не значит, что антивирусы не нужны. Просто мы признаём, что их отключение — это нарушение правил игры. Точно так же, если мы отключаем UAC для пользователей — то по этой же логике мы не должны пользоваться RunAs — иначе это тоже будет нарушение правил игры.

Поэтому если мы ставим «Automatically deny» в групповой политике (как рекомендует Vista Security Gude) — то логичным продолжением будет запретить RunAs по хешу, а также известные аналоги (вроде Sysinternals ShellRunAs).

KomatoZo комментирует...

Дык... Да, не средство защиты, а, скорее, средство для помощи в деле сохранения целостности. Так же как и NAP.
Кстати, я до сих пор не понимаю, чем поможет RunAs пользователю, который не имеет пароля администратора?

проничкин комментирует...

Нет, ну если пользователь с ограниченными не знает пароля — то ему ни разу не поможет ни RunAs, ни запущенный UAC. Речь идёт как раз о том случае, когда пароль он всё-таки знает. То есть самый распространённый способ использования UAC — ты сидишь под ограниченным пользователем, а в нужный момент вводишь пароль UAC. Но это, как мы уже выяснили, не очень секурно. И вот дальше уже получается, что классический runas несекурно точно по тем же причинам.

KomatoZo комментирует...

Так никто и не спорил никогда, что обезьяна с гранатой опаснее, чем такая же, но без гранаты =)
О чем мы тут с тобой спорим-то тогда вообще на протяжении трех страниц??? =)))))

проничкин комментирует...

да в общем-то я бы не назвал это спором. Просто вырабатываем чёткие формулировки по основным позициям. А основная мысль, с которой всё началось — есть ситуации, когда UAC это хорошо, и когда есть «понятные причины его не выключать». Но есть и более другие ситуации, когда UAC это уже не так здорово — и есть не менее понятные причины его не включать =).

KomatoZo комментирует...

=)
Кстати, хорошо бы программеров потерзать - а будет ли так легко влезть в сессию, если совместить UAC с виртуализацией?

проничкин комментирует...

Ты имеешь ввиду виртуализацию путей/реестра в висте? Или классические ВМ? Или что-то вроде софтгрида?

KomatoZo комментирует...

Скорее, первое. Будет это мешать/помогать перехвату сессии?

проничкин комментирует...

так вот, по поводу виртуализации. Насколько можно понять из описания этой фичи в статье Руссиновича, она служит сугубо утилитарной цели. А именно, предотвратить ошибки при попытках записи в системные области. То есть вот сидишь ты под пользователем с ограниченными правамИ, запускаешь некую прогу, которая хочет сохранить свои настройки в c:\windows. У неё это, естественно, не получается. И тут виртуализация р-р-раз! — и подсовывает вместо с:\windows хитрую папочку в твоём профиле. Так, что приложение ничего не замечает, продолжает работать и думает, что живёт в c:\windows.

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

Кстати говоря, Руссинович также придерживается озвученного мною подхода к UAC: «…malware could wait for a standard user’s OTS elevation, intercept it, and use a Trojan horse dialog to capture administrator credentials. With those credentials they can gain access to the administrator’s account and infect it. For this reason, OTS elevations are strongly discouraged in corporate environments».

KomatoZo комментирует...

Про виртуализацию понял.
Про UAC - опять бред. Нет никакой защиты на компьютере, если на нем поселился хоть один зловред. Если компьютер заражен, то не поможет никакое ухищрение. И UAC тут ни при чем абсолютно. Тут нужнуже совсем другие средства включать. Лечить. Убивать. Увольнять. Но не говорить, что вот, мол, UAC нас не защищает, когда на компьютере есть вирус. Он и не должен. Он должен отрабатывать ДО попадения зловреда на винчестер. После он уже бесполезен, в этом ты меня убедил.

G14 комментирует...

"Про UAC - опять бред. Нет никакой защиты на компьютере, если на нем поселился хоть один зловред."
Саш, почему бред? Руссинович ведь говорит не о зараженном компьютере, а о процедуре заражения. ПРичем у Марка, как я понимаю, речь даже не о заражении. Смотри, я пишу простую програмку, которая умеет две вещи:
- выводить окошко, очень похожее на запрос повышения от UAC
- отсылать все что введут в окошке на адрес Х (или складировать в незащищенное место - папочку в куче пользовательских папок)
По сути это не совсем заражение. НО это даже ОПАСНЕЕ заражения ибо в корпоративной среде (а ввод логина и пароля в окошке повышения дома не пользуют в основном)таким образом совсем нетрудно собрать несколько паролей с "непользовательскими" правами. Даже если пользователь не знает аккаунт с правами который "примет" UAC (как и должно быть)- всегда есть шанс, что пользователь позовет мальчика из поддержки и тот по наивности введет свой. Что СУЩЕСТВЕННО облегчает последующую атаку. Именно поэтому в корпоративной среде UAC для пользователей - зло.
По сути - UAC включенный для пользователей в корпоративной среде есть ни что иное как провокация социальной инженерии. :)

KomatoZo комментирует...

Отправиться что ли на курсы риторики? Если я не могу донести простую мысль до двух умных людей, то плохой из меня оратор.
Как твоя программа, которую ты написал, попадет к пользователю? Каким методом ты ее туда доставишь? Та херня, которая реализует подобную логику это "зловред". Это троян или кейлоггер. Или как ты там еще его назвать можешь, Леш.
Потому машина, на которой стоит такой софт уже заражена. И после этого абсолютно пофиг уже - есть UAC или нет его =)

G14 комментирует...

Да ладно. Я пошлю ее по почте, впарю на флешку, придумаю еще сотню способов чтобы она попала в руки любопытному юзеру.
Как вариант - подсмотрю какой модели флешка у менеджера Васи, куплю такую же и подменю флешки пока буду трахать ему моск и рассказывать про пиво и голых женщин. Это старые способы. Их море.
При этом она не будет устанавливаться. Я не хочу, к примеру, чтоб она жила долго на компе в надежеде поймать много паролей. Я хочу, чтобы ее всего раз запустили.
И при этом, внимание, UAC НЕ будет задействован. Прога просто сама сгенерирует "окно, похожее на UAC". И если пользовательям UAC включен - это может не вызвать подозрение у техника саппорта, разве что "а козлы опять кривой софт написали". При отключеном UAC это точно вызовет подозрения.

KomatoZo комментирует...

Абсолютно правильно. Только с такой же вероятностью эта программа может имитировать окно авторизации на прокси, или на сайте, или на фаловом ресурсе. Эти окна иногда возникают, когда что-то сломалось. Только при чем тут UAC? Не говоря о том, что как только такой софт станет распространенным, его тут же начнут ловить всякие антивири.
Я уже не говорю о том, что эта программа может отрисовывать окно входа в систему, если пользователь, например, отошел от компа на пару минут. Причем то окно, которое не будет просить его нажать "три болта", а только предложит ввести пароль. Хочешь поспорим, сколько обычных пользователей попадутся на эту удочку? Я думаю, что процентов 70-90.

G14 комментирует...

Точно. При этом:
- Пользователь каждый день видит окно ввода пароля в Windows
- С окнами авторизации на прокси и т.п. может быть то же самое

Теперь самое, на мой взгляд, интересное. Пользователь привык вводить в эти окошки пароли. Он воспринимает эти окошки как часть рабочего процесса и вводит пароль не задумываясь. Он НЕ позвонит в саппорт если увидит знакомое окно, он просто введет пароль.
Так вот - включеный пользователям UAC скоро тоже станет "знакомым окном". И все будут вводить креденшлы на автомате.
Я не против UAC как такового, но в этом случае считаю наличие UAC включенным для пользователей - вредным. Ибо он приучает их к нехорошему.
Использование "окна, похожего на UAC" в целях спереть пароль ничем не лучше и не хуже использования более других окон. Просто это еще одна потенциальная брешь. И поэтому я думаю, что UAC для пользователей вреден.

KomatoZo комментирует...

Угу. Давай по этому поводу отменим вход в систему. UAC помогает в общем случае снизить вероятность зараения компьютера вирусами и руткитами. То, что он становится еще одни поводом для применения социальной инжернерии достаточно слабый аргумент, хотя бы потому, что ты сам признал, что положить такую программу на компьютер может только инсайдер или человек, который другим способом имеет физический доступ к компьютеру или другому оборудованию пользователя. Это совершенно другая область безопасности и с этими угрозами нужно бороться тоже по другому.
Предвосхищая вопрос прото, что "можно типа загрузить пользователю эту программу с www", то можно было бы процитировать кого-то из MS безопаснков, который не так давно в блоге сказал, что защитить пользователя от него самого крайне сложно. Почти невозможно. Нужно обучать пользователей, нужно провоить комплексную стратегию защиты и бла-бла-бла...
Пока же вы напару убедили меня только в том, что UAC делает зараженный компьютер еще более уязвимым. Незараженный же - напротив, делает более устойчивым к техническим воздействиям. Пользователь, к которому в любом виде успешно применена социальная инженерия это такой вирус, от которого защиты пока нет. Разве что плаха... =)

G14 комментирует...

"UAC помогает в общем случае снизить вероятность зараения компьютера вирусами и руткитами."

Объясни, когда вероятность заражения руткитом выше у простого пользователя: при включенном UAC и шансе повысить права процесса или при отключенном UAC?

KomatoZo комментирует...

При отключенном. При включенном они вообще пока не ставятся =)
Просто физически.
Кроме того, ты меня таки не читаешь. Я уже сказал, что у пользователя не должно быть шанса повысить привилегии. Только отключение UAC тут ни при чем.

cybercop комментирует...

Хочу сказать свои 5 копеек. UAC мне не мешает работать. Более того, считаю, что пользователи (увы, бараны в большем числе) нуждаются в поводыре, который Микрософт и попыталась сделать. Те советы, которые призывают к его выключению, однозначно считал и считаю вредными! А то, что кому-то неудобно работать - простите, а когда повышенные требования к безопасности давали облегчение в работе?
С уважением Vlad MVP Windows Security

Анонимный комментирует...
Этот комментарий был удален администратором блога.