Джоанна Рутковска: Наши системы слишком «дырявые»

Джоанна Рутковска:
Наши системы слишком «дырявые»

Утверждают, что, укрепив оборону серверной части компании, можно спать спокойно. Данные нужно серьезно защищать и на десктопах, убеждена Джоанна Рутковска

Джоанна Рутковска (Joanna Rutkowska) – в 2007 году создала собственную лабораторию Invisible Things Lab. Этот проект был изначально детищем двух специалистов, работавших в компании Coseinc, – ее, выпускницы кафедры электроники и информационных технологий Варшавского политехнического университета, и Александра Терешкина, окончившего Таганрогский государственный радиотехнический университет. Годом позднее в команде лаборатории появился Рафаль Войчук (Rafal Wojtczuk), работавший ранее в компании McAfee. Основное направление работы Invisible Things Lab – анализ работы механизмов защиты в разных операционных системах, исследование возможностей виртуальных сред и оказание консультационных услуг, так или иначе связанных с безопасностью.

Джоанна, можете ли вы оценить угрозы безопасности, существовавшие пять-десять лет назад, и те, что появились сегодня?

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

Когда вы начинаете об этом размышлять, то становится очевидным, что все пользовательские данные в конечном итоге перемещаются на настольную систему – для дальнейшей обработки либо визуализации пользователю.

У вас может быть очень защищенная сетевая инфраструктура, серверное оборудование и шифрованные сетевые протоколы. Но! Если ваша настольная система уязвима к атакам, т.е. скомпрометирована, то считайте, что все остальные ухищрения по безопасности уже не важны.

Есть ли у виртуализации на уровне процессора сильные стороны? Что можно назвать «ахиллесовой пятой» виртуализации?

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

Для этого есть две предпосылки. Во-первых, аппаратное обеспечение проходит более полный цикл верификации продукта. Во-вторых, некоторые вещи легче выполнить на аппаратном, чем на программном уровне. Виртуализация является хорошим примером: на аппаратном уровне реализовать функции VT-x или AMD-V намного легче, нежели программировать бинарную трансляцию, как это было выполнено в прошлом в продуктах VMware.

Некоторые функции также невозможно выполнить через программную реализацию. Яркий пример – реализация IOMMU/VT-d (не путайте с VT-x) либо Intel TXT.

Но иногда «взламываются» и аппаратные начинки. Интересно, что подходят к такому процессу с точки зрения уязвимости только программной части. Несколько лет назад мы продемонстрировали такие уязвимости, обойдя защиту Intel TXT и механизм защиты SMM.

Что более чревато неприятными последствиями: настольная машина, с физически поврежденными носителями из-за вирусной активности или действия червей, либо потеря персональной информации?

Аппаратура кажется ценной, если вы ребенок или тинэйджер. Однако с точки зрения бизнеса, ценится все-таки информация, а не ее носитель. Первая может быть просто бесценной по сравнению с «железом».

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

У микропроцессоров есть функция загрузки микрокода для исправления ошибок или недочетов, допущенных в процессе дизайна. Каковы шансы, что такой микрокод, но с вредоносными намерениями может быть подготовлен?

Шансы очень небольшие. У этих микрокодов есть специальная цифровая подпись, чтобы микропроцессор принимал только оригинальное обновление от производителя.

Вторая проблема – отсутствие информации о том окружении, где будет выполняться этот микрокод. Он не написан на ассемблере для x86 или любом другом широко известном ассемблерном языке, по большому счету это описание конфигурации вентилей.

Так что, даже если кому-то удастся обойти механизм загрузки микрокода, все еще будет проблематично написание вменяемого кода (например, реализация «черного хода» в самом микрокоде). И, конечно, не стоить забывать следующее – это описание процедуры «черного хода», а не сама атака. Атакующий «уже» должен иметь администраторские права, чтобы хотя бы начать саму попытку загрузки микрокода.

Раньше много говорили о концепции прозрачного гипервизора, размещенного на самом низком уровне – BIOS. У данного гипервизора была бы «красная» кнопка, которая инициализировала бы SMM-механизм прыжка в безопасное окружение. Это все еще мечта?

Это не мечта, просто неправильный путь. Подход с антивирусом – неправильный, чему мы были свидетелями в прошедшие годы. Это немасштабируемое решение. Более того, антивирусы не способны работать с новыми видами атак. Современные ОС настолько сложны, что невозможно подготовить какой-либо эффективный сканер целостности, который бы однозначно отвечал на вопрос: «Эта система скомпрометирована?» Даже если бы у нас был надежный доступ к системной памяти, все равно получается неоднозначный вариант. Кроме того, мне кажется, что дать точное определение термину «подозрительная активность» в ОС Windows или Linux уже невозможно.

Будь вы ИТ-директором на большом предприятии, какие бы предприняли меры для повышения информационной защиты компании?

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

Есть способы организовать рабочее место в плане безопасности?

Для нынешних настольных систем, таких как Windows, Linux или Mac – нет. Именно поэтому мы начала работать над Qubes OS.

Какие цели вы ставили когда задумывались над ее дизайном? От каких рисков пользователь будет защищен, работая в Qubes OS?

В системе Qubes главный принцип – это использование методики «Безопасность путем изоляции» (Security by Isolation). Путем задействования механизма виртуализации получается изолировать разные программы друг от друга и даже поместить многие системные компоненты, такие как сетевой стек и подсистему хранения, в «песочницы». Поэтому, даже если они будут скомпрометированы, для системы никакого ущерба не приключится.

Qubes помогает пользователю определить множество уровней безопасности, выполненных в виде легковесных виртуальных машин (AppVM). Например, пользователь может работать с виртуальными машинами: personal, work, shopping, bank или random. При этом работа приложений в этих виртуальных машинах, в общем-то, ничем не отличается от обычного запуска. Кроме одного момента: все приложения изолированы друг от друга. Qubes также поддерживает безопасную операцию копирования и вставки и файловый обмен между разными AppVM.

Вы планируете выпускать Qubes на основе только дистрибутивов Red Hat, или же есть планы охватить все основные Linux дистрибутивы?

Мы не планируем выпускать Qubes на основе какого-либо дистрибутива. Напротив, начиная со следующей версии Qubes будет выпускаться как отдельная ОС, со своим инсталлятором, так что предварительная установка Linux больше не потребуется (сейчас необходимо, чтобы пользователь заранее поставил минимальный набор программ из Fedora 13).

Нынешняя версия основана на Fedora 13 и задействует ее репозитории. Нужно ли будет и в следующей версии подключать эти репозитории, чтобы устанавливать обновленные пакеты?

Глобальный дизайн в Qubes заключается в том, что вам не нужно будет даже обновлять пакеты в пространстве Dom0. Во-первых, потому, что в пространстве Dom0 нет сетевого соединения. Во-вторых, из-за того, что фактически там нет запускаемых приложений. В виртуальных же машинах AppVM, NetVM у вас будет Fedora, которую можно обновить из репозиториев.

Антон Борисов

Интервью на английском (оригинал)

Interview with Joanna Rutkowska on security issues

Q1: Joanna, you"re the founder of Invisible Things laboratory and known for multiple security reports worldwide. When have you realized, that computer security sphere is interesting for you?

A1: It"s been so long ago, that I don"t remember anymore ;)

Q2: You and your team have a very rich experience and portfolio. Could you please estimate the security concerns a decade ago, 5 years ago and now days? How the "harmful"/"virulent" ecosystem has changed? Worms began to be hard-to-detect, viruses re-established special crypto features, or there"s something else?

A2: The biggest security concern has not changed over the last decade, and is unlikely to change anytime soon I think. In my opinion, the single most important aspect in IT security is *desktop security* (here by the traditional term "desktop" I just mean "end-user" systems, like desktops, laptops, workstations, smartphones, tablets).

When you think about it, it should be quite obvious -- *all* the user data must eventually make it to his or her desktop: for processing and for presentation to the user. So, you can have the most secure infrastructure, servers, network encryption protocols but if your desktop is compromised, it is all lost!

Q3: From your point of view -- what are the strong sides of virtualization at CPU level, and at the same time -- does virtualization have a weak side?

A3: We generally tend to be believe that whatever is implemented in hardware should be more secure than the same thing implemented in software.

There are two reasons to believe this: hardware usually goes through a more complete verification process, and, second, that some things are simply easier to implement in hardware than in software. Virtualization is a good example: it"s much easier to implement it on a CPU level (VT-x, or AMD-V), then through a tricky software (binary translation as used e.g. by VMware in the past). Some things are also not possible to be implemented in software -- a good example is IOMMU/VT-d (do not confuse with VT-x) or Intel TXT.

But, of course, there are exceptions, and sometimes people also break the hardware, most interestingly people come up with *software-only* attacks against hardware. My team has shown examples of several such attacks a few times in the past years (e.g. bypassing Intel TXT, or attacking SMM).

Q4: What is the worsest thing -- to have a PC, physically damaged by a virus / a worm or losing a personal, private information due to a virulent activity?

A4: Hardware might seem valuable when you"re a kid or a teenager. But for businesses hardware is cheap compared to the value of the data, which might be indefinitely more valuable than the hardware.

If somebody steals my $3k laptop, I will get money back from the insurance. If somebody steals my data, then I have much buggier problems.

Q5: CPU (at least those, manufactured by Intel) has a capability to load CPU microcode to fix problems at a very low level. What are the chances, that a malicious microcode can be prepared?

A5: Very slim. The CPU microcodes are said to be all digitally signed, so that the CPU would accept only the original microcode from the vendor (Intel or AMD). Another problem is that almost nothing is known about the environment where the microcode executes. Microcode is not written in x86 assembly or any other widely known assembly, it"s more of a gate-configuration description. So, even if somebody found a way to break the load-only-signed-microcode mechanisms, still there is a problem how to prepare any meaningful payload (e.g. backdoor code in microcode).

And, of course, do not forget that this all would be only a *backdooring* technique, not an *attack*, as the attacker would have to have root access already to even start attempting to subvert the microcode.

Q6: Several years ago there were talks about concept of transparent hypervisor, placed at a very low hardware level (BIOS / firmware). This hypervisor should have a "Red" button (triggered via SMM mechanism), in order to escape into 100% safe-environment with antivirus and a couple of other tools to check the integrity of suspended system. Thus far, the user has an option to stop any suspected activity. Is this a dream?

A6: It"s not a dream, it"s simply a wrong way. Antivirus approach is a wrong approach as we all have witnessed in the recent years -- it doesn"t scale well, and most importantly, is unable to cope with new attacks.

Operating systems are so complex that it is impossible to implement effective integrity scanner that would be answering the question: "is this system compromised?". Even if we had reliable access to the system memory (like if we had the integrity checking engine in the hypervisor, or protected VM). And, I"m sure it would be rather difficult to give a definition to "suspected activity" in modern systems like Windows or Linux.

Q7: Does any difference exist between Intel and AMD processors -- in terms of virtual features, execution bit protection and so forth?

A7: Yes, there are some differences, rather irrelevant from security point of view (or at least they seem to me security-irrelevant).

Q8: Were you a CIO in already running large-scale company -- what first steps would you do to protect enterprise environment and to provide a necessary level of security?

A8: Frankly, I don"t know. Because I"m not planning to become a CIO anytime soon. Being a CIO is an administration type of job, and I"m interested in technical jobs, like being a researcher or a system architect. In my opinion our systems are so buggy that even if users are security conscious, they still can be attacked.

Q9: So, no way to keep the working environments safe and secure?

A9: With current desktop OSes like Windows, Linux, or Mac -- no. That"s precisely the reason why we have started working on Qubes OS.

Q10: What goals were set to design it, and what risks an user will be guarded from once he/she will stick with Qubes OS?

A10: Well, Qubes implements Security by Isolation approach. To do this, Qubes utilizes virtualization technology, to be able to isolate various programs from each other, and even sandbox many system-level components, like networking or storage subsystem, so that their compromise don"t affect the integrity of the rest of the system.

Qubes lets the user define many security domains implemented as lightweight Virtual Machines (VMs), or "AppVMs". E.g. user can have "personal", "work", "shopping", "bank", and "random" AppVMs and can use the applications from within those VMs just like if they were executing on the local machine, but at the same time they are well isolated from each other. Qubes supports secure copy-and-paste and file sharing between the AppVMs, of course.

Q11: Do you plan to release Qubes atop of RedHat only, or there are plans to make it available for all major distributions as well?

A11: We do not plan to release Qubes atop any Linux distribution. Starting from the next version (to be released within 1-2 months), Qubes will become a standalone operating system, with its own installer, and would not require prior installation of any Linux distribution (it now requires that user first install minimal Fedora 13, but this is only temporary).

Q12. Okay, the current version of Qubes is based on Fedora distribution and uses Fedora"s repositories as well. Will the next version of Qubes be using it as well, in order for user to have up-to-date packages?

A12: The whole point about Qubes, is that you don"t need to keep packages in Dom0 up-to-date, because there is no networking in Dom0, and because there are effectively no applications running there. In AppVMs, or NetVM, you have pretty much regular Fedora, on the other hand, that you update from Fedora repos.

Комментарии могут оставлять только зарегистрированные пользователи