Требуется пеннартур
Я что-то ничего не понимаю. Как добавочный режим процессора влияет на безопасность приложений?http://en.wikipedia.org/wiki/Blue_Pill
Но вообще - согласен, бред. Ноутбук можно ещё и разбить кувалдой, после чего осколком стекла от экрана перерезать себе горло - и что? Если так уж хотели отключить эту фичу, сделали бы её отключенной по дефолту, но включаемой.
ЗЫ: Ну и при чём тут я?
ЗЫ: Ну и при чём тут я?ты специалист по сони и винде, и ты мог бы понять что имелось в виду.
Твоя ссылка забавная:
Blue Pill is the codename for a controversial rootkit based on x86 virtualization technology that targets Microsoft's Windows Vista operating system.Пока я не понял, почему они отказались от процессора а не от оси
Пока я не понял, почему они отказались от процессора а не от осиДа ты, видимо, вообще ничего не понял. Уязвимость - в самой идее виртуализации, был реализован руткит для амдшной и интеловской виртуализации, и продемонстрирован на примере висты (ну не на примере xp же демонстрировать). Ну будешь использовать ты не висту, а другую ось - и что от этого изменится? Даже если Blue Pill в текущей форме будет для этого неприменим - его можно будет легко модифицировать.
Но, насколько я понимаю, основная идея blue pill - чтобы его нельзя было обнаружить _после_ установки А как его установить - отдельный большой вопрос.
ты специалист по сони и виндеЭто с каких пор?
Это с каких пор?у тебя на этом форуме такая репутация. привыкай.
Ну будешь использовать ты не висту, а другую ось - и что от этого изменится?ну поставлю я vmware esx или solaris+xvm, как ты думаешь не заметят они, что оказались внутри виртуалки?
ну поставлю я vmware esx или solaris+xvm, как ты думаешь не заметят они, что оказались внутри виртуалки?а как это можно заметить?
а как это можно заметить?есть два варианта атаки
1) нас заперли в клетке и не выпускают за пределы виртуальной машины
2) нас закрыли в клетке, но засов не висит и выйти из виртуальной машины можно
Первый вариант обнаруживается по факту отключённой аппаратной виртуализации. Ось, которую атакуют таким образом, не может использовать аппаратную виртуализацию, потому что запущена в режиме процессора, когда к соответствующим флагам нет доступа. Если известно, что проц с аппаратной виртуализацией, а софт внутри ос её не видит, значит ось сидит сама в виртуальной машине. Чтобы было понятнее: внутри виртуализованной оси нельзя запускать другой софт с аппаратной виртуализацией. Обоснования, примеры и рассуждения могу привести отдельно.
Второй вариант обходится просто - ось выходит из виртуальной машины, получает полные права доступа и больше никого к ним не подпускает. После чего сканируется винчестер на предмет заныканных руткитов.
Первый вариант обнаруживается по факту отключённой аппаратной виртуализации.хаха. в kvm уже реализовали nested svm, похоже just for lulz.
Если известно, что проц с аппаратной виртуализациейcpuid это первое что перехватывают
Второй вариант обходится просто - ось выходит из виртуальной машины, получает полные права доступа и больше никого к ним не подпускает. После чего сканируется винчестер на предмет заныканных руткитов.Что, прямо в полете становится гипервизором?
Второй вариант обходится просто - ось выходит из виртуальной машины, получает полные права доступа и больше никого к ним не подпускает.при правильной виртуализации - ось будет только считать, что у нее полные права.
cpuid это первое что перехватываютПечально. А ведь модель проца можно ещё и на коробке от него посмотреть или на документации к ноуту
Что, прямо в полете становится гипервизором?А как это по-твоему ещё происходит? Компьютер вообще стартует отнюдь не в защищённом режиме
Ну ты написал, как я понял, что ось после загрузки в непривилегированном домене может стать гипервизором, верно? Или я не так понял?
при правильной виртуализации - ось будет только считать, что у нее полные права.Это называется не виртуализация, а эмуляция и действительно является необнаружимой. Тем не менее её тоже вычисляют через статистику по скорости работы системы и по задержкам в процессе прямых обращений к устройствам, который возрастают вследствие софтварной обработки эмулирующей программой. Вот только для этого вовсе не обязательно иметь доступ к аппаратной виртуализации, эмуляцию можно наладить и на более простой основе
Ну ты написал, как я понял, что ось после загрузки в непривилегированном домене может стать гипервизором, верно? Или я не так понял?Правильно понял. Только при условии, что её туда пускает гипервизор. Случай, когда она замыкается в непривилегированном домене рассмотрен в первом пункте. Второй пункт показывает, что если гипервизор не хочет палить своего присутствия и открывает оси доступ к флагу виртуального режима, то следы гипервизора всё равно будут обнаружены
Тем не менее её тоже вычисляют через статистику по скорости работы системы и по задержкам в процессе прямых обращений к устройствам, который возрастают вследствие софтварной обработки эмулирующей программой.так вот чтобы таких задержек не было, эмуляцию делают через правильную аппаратную виртуализацию - а не через софтварную
Мм, а пример можешь привести? Я не припоминаю, чтоб так можно было делать где-либо.
Не, так нельзя, если ты будешь использовать фулл виртуализацию, исчезнет vmx/svm cap для проца, зато нельзя будет отличить по задержкам, если будешь использовать эмуляцию, то она чисто софтовая и будет давать временные лаги. Даже если можно наклепать такой гипервизор, который в capabilities будет пробрасывать все как есть, то все обломается при первой же попытке заюзать аппаратную виртуализацию в госте.
Мм, а пример можешь привести? Я не припоминаю, чтоб так можно было делать где-либо.Не могу. Современный гипервизоры предпочитают гарантировать надёжность работы, чем скрываться при первой же попытке проверить, не управляется ли ось из гипервизора. Если ты не понял, я рассматриваю ситуацию с гипервизором, который хочет остаться не замеченным, а не тем, который хочет управлять машиной. Для достижения этой цели необходимо исчезнуть со сцены, передав полномочия взыскующей системе, при первых её попытках перехватить управление.
Что касается непоняток с аппаратной виртуализацией, я отвечу тёмно-серому в этом же посте.
Как устроена аппаратная виртуализация: процессору добавляется ещё один флаг, который отвечает за режим работы (привилегированный/непривилегированный). В привилегированном режиме добавляется возможность изменять этот флаг, а также выполнять некоторые новые инструкции, в частности устанавливать перехватчики для операций с железом и прочих операций, которые выполнять можно только в нулевом круге. Эти операции перехватываются и обрабатываются гипервизором, а хардварная виртуализация способствует упрощению этого процесса.
Почему нельзя внутри аппаратной виртуализированной системы использовать аппаратную виртуализацию: потому что доступа к соответствующим инструкциям (аппаратным) у неё нет. Фактически виртуализованный процессор имеет некое подмножество инструкций базового, не включающее аппаратное ускорение, что правильно. При желании внутри системы можно воспользоваться софтварным ускорением, либо вместо аппаратных инструкций гипервизор может предоставить эмулируемый софтварно тот же самый набор инструкций "аппаратного" ускорения, и тогда внутри системы можно будет использовать это псевдоаппаратное ускорение.
Аппаратная виртуализация - сравнительно новая технология, и не все в ней разобрались. Приведу аналогию задачи для более привычного случая. Пусть у нас есть процесс, предназначенный для запуска в ring0. Как скрыть от него, что он запущен в ring3? Можно не давать ему полномочий для работы с железом (чтобы не упала наша система но тогда он обнаружит, что запущен с пользовательскими привилегиями. Можно дать ему полные привилегии на самом деле, но тогда программа, их передавшая, пострадает сама. Можно сделать эмуляцию железа софтварно, но тогда это уже будет эмуляция, которая очевидно возможно в любом случае и столь же очевидно неэффективна. В частности поэтому не имеет решение задачи запустить одну ось внутри другой без тормозов либо расширения набора инструкций процессора (аппаратной виртуализации)
Не могу. Современный гипервизоры предпочитают гарантировать надёжность работы, чем скрываться при первой же попытке проверить, не управляется ли ось из гипервизора. Если ты не понял, я рассматриваю ситуацию с гипервизором, который хочет остаться не замеченным, а не тем, который хочет управлять машиной. Для достижения этой цели необходимо исчезнуть со сцены, передав полномочия взыскующей системе, при первых её попытках перехватить управление.Я не совсем точно выразился, наверное, но, насколько мне известно, в принципе нельзя у запущенной системы переключать контекст домен-гипервизор.
Я не совсем точно выразился, наверное, но, насколько мне известно, в принципе нельзя у запущенной системы переключать контекст домен-гипервизор.я думаю, это может сделать для домена гипервизор. В конце-концов при обращении к гипервизору происходит прерывание домена, и для восстановления работы где-то в памяти лежит вся необходимая информация. Может быть стандартная инструкция восстановления работы сама проставляет флаг домен/гипервизор, но тогда можно обойтись без неё, выполнив вместо неё от имени гипервизора простенькую процедру. И тогда домен станет гипервизором, а гипервизор - никем
Ну даже если так, то действия Сони дурацкие, потому что гипотетический троян, отдав управление, обратно его не заберет, а чтобы это проверять, достаточно проводить простенький чек при старте системы, или, что лучше, юзать гипервизор в биосе, что намного приятнее для конечных пользователей.
Полностью с тобой согласен. Если ты не заметил, я с самого начала сказал, что этот руткит легко обнаружить. Он не страшнее запуска системы в виртуальной среде. Решений множество: отключить функциональность процессора в биосе, запускать гипервизор в биосе (что плохо сказывается на пробросе видюхи и прочего железа вкомпилить гипервизор в ядро (kvm) и периодически проверять им на наличие аппаратных возможностей проца. Фактически эмуляция и то опаснее будет (виндоюзер может и не заметить тормозов, списывая их на привычные лаги системы).
И я не думаю, что инженеры Сони настолько тупы, чтобы этого не понимать. Просто менеджеры придумали пиар-акцию, которая объяснит почему в их буки будут вставляться процессоры с ущербными наборами инструкций, ведь далеко не все дубовые коры, например, имеют при себе аппаратную виртуализацию. Я полмесяца назад выбирал ноут в uti-note.ru, но так и не нашёл ни одной старой дубовой коры с аппаратной виртуализацией, она оказалась только в сравнительно новых пенринах.
И я не думаю, что инженеры Сони настолько тупы, чтобы этого не понимать. Просто менеджеры придумали пиар-акцию, которая объяснит почему в их буки будут вставляться процессоры с ущербными наборами инструкций, ведь далеко не все дубовые коры, например, имеют при себе аппаратную виртуализацию. Я полмесяца назад выбирал ноут в uti-note.ru, но так и не нашёл ни одной старой дубовой коры с аппаратной виртуализацией, она оказалась только в сравнительно новых пенринах.
Просто менеджеры придумали пиар-акцию, которая объяснит почему в их буки будут вставляться процессоры с ущербными наборами инструкций, ведь далеко не все дубовые коры, например, имеют при себе аппаратную виртуализацию.В новости сказано:
Компания Sony заблокировала функцию аппаратной виртуализации на своих ноутбуках VaioЯ понимаю это, как блокирование соответствующей фичи на поддерживающих её процессорах, а не как отсутствие фичи.
я с самого начала сказал, что этот руткит легко обнаружитьНу вот создатели blue pill говорят, что обнаружить нельзя. Правда, так и не доказали.
Ну вот создатели blue pill говорят, что обнаружить нельзя. Правда, так и не доказали.а создатели red pill доказали что доказать нельзя =)
Ну вот создатели blue pill говорят, что обнаружить нельзя.ну не знаю. А я говорю, что можно. Попробуй логически решить какая версия кажется более правдоподобной (на всякий случай ещё раз прочитай мои объяснения)
Оставить комментарий
yroslavasako
Я что-то ничего не понимаю. Как добавочный режим процессора влияет на безопасность приложений?