В системе виртуализации Xen найдена уязвимость (http://permalink.gmane.org/gmane.comp.security.oss.general/8324), дающая возможность администратору гостевого окружения, имеющего доступ к графической консоли гостевой системы (VNC или SDL) , перейти в режим мониторинга QEMU, через который можно добраться до ресурсов хост-системы и других гостевых окружений. Используя данные ресурсы атакующий может теоретически получить повышенные привилегии на уровне хост-системы.
Гостевые системы, работающие в режиме паравиртуализации без графической консоли, проблеме не подвержены. Настройка "monitor=no" или "monitor=0" не влияет на проявление уязвимости. Уязвимость проявляется при использовании xend/xm, libxl/xl и libvirt во всех версиях Xen, начиная с 4.0, за исключением конфигураций на базе Xen Cloud Platform. Для перехода в режим мониторинга QEMU достаточно нажать CTRL+ALT+2 (перебирая цифры с 2 до 6) до появления приглашения "QEMU version monitor". В качестве обходного варианта для защиты можно отключить консоль мониторинга QEMU через команды 'device_model_args=["-monitor","null"]' для xl в Xen 4.1 или 'monitor_path="null"' для xend, для libvirt проблема решается только патчем.URL: http://permalink.gmane.org/gmane.comp.security.oss.general/8324
Новость: http://www.opennet.me/opennews/art.shtml?num=34771
Вот Йоанна Рутковская растроится.
> Вот Йоанна Рутковская растроится.Не расстроится.
Не, расстроится.
> Не расстроится.Растроится. Хотя-бы за то что по русски это обычно звучит как Джоанна :)
Ничего, она ещё 3 года Xen попилит и наступит щастье :) хотя, начинать надо было с Xen, наверное.
Хотя, ерунда это всё. С таким количеством багов в десктопных и серверных процессорах (в каждом семействе десятки или сотни) безопасности всё равно не будет.Для уменьшения количества дырок надо не усложнять систему (как у Рутковской, наворочен зоопарк велосипедов), а наоборот упрощать. Для секурных операций физически отдельное железо, можно старенькое, закрытое другой железкой-фаерволом и т.д. Баловство (игры, инет) - на отдельном помойко-ПК.
>в каждом семействе десятки или сотниТысячи. В Core2Duo было не менее 2000. Крис демонстрировал удаленной взлом компьютера с таким процессором с любой операционной системой, хоть freedos.
>Для уменьшения количества дырок надо не усложнять систему (как у Рутковской, наворочен зоопарк велосипедов), а наоборот упрощать.Как конкретно вы предлагаете упрощать архитектуру x86? Intel, надо отдать ему должное, пытался, см Itanium, закончилось все полным провалом. Большинство вами упомянутых "усложнений" это или исправление ошибок архитектуры или реакция на них.
> Intel, надо отдать ему должное, пытался, см Itanium, закончилось все полным провалом.Это Итаник-то упрощение x86??? Бу-га-гашеньки. Там своих сложностей сорок четыре чемодана
Чтобы перевести процессор в нативный для него 64-разрядный режим работы нужно:
1. в Итаниум: ничего
2. в х86: открыть а20, создать таблицу прерываний (IDT), создать таблицу страничной адресации памяти (PML4T), создать таблицу прав контроля доступа к памяти (GDT), перепрограммировать контроллер прерываний (PIC), включить и настроить APIC по PIC, получить таблицу устройств из PCI и раскидать их по прерываниям, настроить управление электропитанием, ...Чтобы переключить видеорежим средствами BIOS/UEFI:
1. в Итаниум: вызвать функцию переключения видеорежима
2. в х86: такая функция гарантировано есть только в реальном режиме, т.е. нужно проделать всю инициализацию в обратном порядке, переключить видеорежим и повторить инициализацию вновь перейдя в нативный long mode.Чтобы активировать многозадачность:
1. в Итаниум: ничего
2. в х86: перейти в защищённый или длинный режим, найти и распарсировать таблицу RSDT, в ней найти и распарсировать таблицу RSDP, в ней найти таблицы отдельных вычислительных ядер, на основании настройки из таблицы провести инициализацию многозадачности, для каждого ядра произвести инициализацию (см. "Чтобы перевести процессор в нативный для него 64-разрядный режим работы"), учесть что также данные по многозадачность можно вынуть из PCI и MSI, и они дают больше данных, но данные могут быть противоречивы и обработка данной ситуации лежит на разработчиках.Продолжать можно долго. Для хомячка на верхнем уровне разницы, как вы правильно заметили, нет.
Угу. Перечислили комплект явных маразмов x86-й архитектуры и с гордостью заявили, что в Итанике ничего подобного нету.А ничего, что:
- сложность оптимизирующего компилятора под Итаник зашкаливает даже на фоне не совсем, мягко говоря, простого в применении x86?
- обращение с числами с плавающей точкой требуется нежнейшее, иначе пойдут постоянные аппаратные исключения и обращения к блоку кода эмуляции?
- в одну инструкцию пакуется несколько действий, исполняемых в непредсказуемом заранее порядке?И при этом всем средняя плотность кода снижается раза в два по сравнению с тем же x86 или POWER - см. размеры бинарников для соответствующих платформ.
Как говорится, от хомячка слышу ;)
Я привёл не "маразмы", а наследие, от которого архитектура от Интел должна была нас избавить.Сложность оптимизирующего компилятора зашкаливает: зашкаливает для вас. Потому что прочими он был написан.
Обращения к числам: программирование вообще точная наука вообще то. Обращение к памяти тоже требуется "нежнейшее" и выбирать какие переменные суммировать / какие функции с какими параметрами вызывать тоже (иначе получите ерунду).
В одну инструкцию пакуется несколько действий: c1=a1+b1, c2=a2+b2, c3=a3+b3 - можете исполнять в произвольном порядке, разрешаю. К слову х86 и ARM работают похожим образом, но это если знать как они работают.
Сравнивать размеры бинарников, не понимая что собственно вы сравниваете, я вам искренне не советую. Напр. в Windows просто код создание пустого WS_OVERLAPPED окна занимает минимум 16 кб, а оптимизированное и на ассемблере лишь 120 байт. Для Линукс аналогично, но это ни о чём ни говорит :).
> Я привёл не "маразмы", а наследие, от которого архитектура от Интел должна
> была нас избавить.Она должна была избавить отнюдь не вас, уважаемый, с вашим домашним вычислительным
центром из игрового писюка, а серверный сегмент. И отчасти избавила.> Сложность оптимизирующего компилятора зашкаливает: зашкаливает для вас.
> Потому что прочими он был написан.Аргумент человека, который явно не в курсе.
> Обращения к числам: программирование вообще точная наука вообще то. Обращение к памяти
> тоже требуется "нежнейшее" и выбирать какие переменные суммировать / какие функции
> с какими параметрами вызывать тоже (иначе получите ерунду).Дело не получаемой в результате "ерунде". Видимо, уважаемый Ваня опять-таки
не в курсе, что Итаник ряд вполне корректных с точки зрения спецификаций
IEEE случаев арифметики с вещественными числами не реализует на аппаратном
уровне. При не особо хитрых аргументах, скажем, умножения двух вещественных
чисел (которые очень даже могут получиться как результат предыдущих
вычислений, и которые не являются специальными случаями типа Inf и NaN)
процессор вместо выдачи результата инициирует аппаратное исключение, которое
ОС должна обработать путем вызова программного блока эмуляции данной операции
через целочисленную арифметику.Последствия для производительности, я думаю, очевидны. Усложнение программирования
(если на производительность не совсем начхать) - я думаю, тоже.Тот же x86, к слову, щелкает такие вычисления молча и с завидной скоростью.
> В одну инструкцию пакуется несколько действий: c1=a1+b1, c2=a2+b2, c3=a3+b3
> можете исполнять в произвольном порядке, разрешаю. К слову х86 и ARM
> работают похожим образом, но это если знать как они работают.Ваня явно не понимает ключевых особенностей процессорных архитектур на базе VLIW
(или, в терминологии Intel, EPIC). А также последствий применения таких архитектур
для компиляторов - см. про сложность оптимизации и плотность упаковки кода.Учите матчасть, уважаемый.
> Сравнивать размеры бинарников, не понимая что собственно вы сравниваете, я вам искренне
> не советую. Напр. в Windows просто код создание пустого WS_OVERLAPPED окна
> занимает минимум 16 кб, а оптимизированное и на ассемблере лишь 120
> байт. Для Линукс аналогично, но это ни о чём ни говорит
> :).Угу, особенно в тему здесь вопрос объема инициализационного кода, который к каждому
исполняемому модулю добавляется один раз и не зависит по объему от объема кода
самого модуля.Сравнивать можно размер бинарников одной версии одного продукта под одну ОС,
но под разные архитектуры. См., например, размер дистрибутива Oracle Database
в вариантах HP-UX/PA-RISC и HP-UX/Itanium. Ну или под OpenVMS/Alpha и OpenVMS/Itanium.
Разница поразительная, а практически все файлы, не являющиеся откомпилированными
программными модулями, идентичны.
Изложено ваши сугубо личное IMHO на которое даже не знаю что и ответить... Написать "Вы идиот?" - грубо и также безосновательно, как и все ваши слова. Взять хотя бы последнее: "Сравнивать можно размер бинарников одной версии одного продукта под одну ОС, но под разные архитектуры". Сравнивать можно что угодно, вопрос в корректности данного сравнения. Вы компилируете один и тот же код? Нет. С одними и теми же настройками компилятора? Нет. Компилятор генерирует идентичный код под обе платформы? Нет. Что вы сравниваете? "практически все файлы, не являющиеся откомпилированными программными модулями, идентичны" - картинка остаётся такого же размера, и текстовый документ тоже.
> Изложено ваши сугубо личное IMHO на которое даже не знаю что и
> ответить... Написать "Вы идиот?" - грубо и также безосновательно, как и
> все ваши слова.Ну раз уж мы решили не грубить...
> Взять хотя бы последнее: "Сравнивать можно размер бинарников
> одной версии одного продукта под одну ОС, но под разные архитектуры".
> Сравнивать можно что угодно, вопрос в корректности данного сравнения.Разумеется. А корректность определяется целями сравнения.
Разговор зашел про плотность упаковки программного кода в разных архитектурах.
Вообще-то общеизвестно, что Итаниумный код - "рыхлый",
общеизвестно и почему - EPIC тому причиной.Итак, имеем на входе один программный продукт с единым исходным кодом,
собираемый под одну операционную систему для разных аппаратных архитектур.
Вдобавок известно (легко выясняется при рассмотрении собранных модулей),
что собраны они практически одним и тем же компилятором - в моем примере
для HP-UX речь идет об HP aCC, для OpenVMS - HP C for OpenVMS.> Вы компилируете один и тот же код? Нет.
Да. С незначительными отличиями, которые не влияют на сравнение в данном случае.
Двухкратная разница в объеме кода при одном и том же функционале не и под одной
и той же ОС - неспроста.> С одними и теми же настройками компилятора? Нет.
В точности неизвестно, но причины различий в настройках с высокой вероятностью
вызваны различиями в платформах - а именно этот фактор мы и анализируем.> Компилятор генерирует идентичный код под обе платформы? Нет.
Как раз плотность кода, т.е. объем полезной работы на байт машинных инструкций,
мы и анализируем ;)> Что вы сравниваете?
Я - плотность кода. А вы?
> "практически все файлы, не являющиеся откомпилированными
> программными модулями, идентичны" - картинка остаётся такого же размера,
> и текстовый документ тоже.Собственно, именно об этом и сказано.
Дистрибутив (если сравнивать его объем целиком) состоит не только из исполняемых
модулей.
> Чтобы перевести процессор в нативный для него 64-разрядный режим работы нужно:
> 2. в х86:в х86-64 ничего не нужно. он стартует в длинном режиме.
3. SPARC - ?
4. PowerPC - ?
5-... другие RISC 64bit ?> Чтобы переключить видеорежим средствами BIOS/UEFI:
> 1. в Итаниум: вызвать функцию переключения видеорежимас каких пор видеорежим переключается функцией *процессора*?
> 2. в х86: такая функция гарантировано есть только в реальном режимеэто не в х86, а в биосе, см. ниже.
> Чтобы активировать многозадачность:
> 2. в х86: перейти в защищённый или длинный режима ничего, что 64-битный проц в длинном режиме стартует? а потом переключается в v86 или что-то другое только потому, что а) ведущая компания-производитель БИОС ленится переписать их под 64-бит б) хомячки юзают 32-битные ОС от ведущей компании-производителя ОС
3. SPARC - ?
4. PowerPC - ?
5-... другие RISC 64bit ?> Продолжать можно долго. Для хомячка на верхнем уровне разницы, как вы правильно заметили, нет.
На верхнем уровне сидит хомячок БГ. Для него разницы нет. Главное, бабло идёт с минимальными потерями на разработки :) А на нижнем уровне хомячки, не понимающие разницы между архитектурой ЦПУ и firmware и функциями ОС и... продолжать можно долго.
> На верхнем уровне сидит хомячок БГ. Для него разницы нет. Главное, бабло
> идёт с минимальными потерями на разработки :) А на нижнем уровне
> хомячки, не понимающие разницы между архитектурой ЦПУ и firmware и функциями
> ОС и... продолжать можно долго.Круговорот хомяков в природе.
На вшах побольше ездят вши поменьше,
Зовутся паразиты.
На вшах поменьше ездят еще меньше,
И так - ad infinitum.
Где вы такой отвратительный перевод раскопали? Вот, ознакомьтесь с тремя качественными вариантами:
http://lipkovichea.livejournal.com/2382319.html
> И так - ad infinitum.Тогда найдите паразитов паразитирующих на вирусах :)
А ссылкой не поделитесь ?
> А ссылкой не поделитесь ?да брешет он, там дальше теоретизирования не пошло.
ЕМНИМ, Крис обещал на одном из defcon сделать презентацию с POC, но как-то это все замялось.
он обещал, но на презентации всё осталось в теории и на слайдах, крыс сказал что сотрудничает с интелом и типа подписал nda, так что пруфоф не будет, я вам вот так вот всё расскажу, а вы потом сами сделаете если чо
насвистел, как обычно. любит он это дело.
show me the code!
> show me the code!Добро пожаловать в мир невидимых вещей - http://theinvisiblethings.blogspot.nl/2009/08/vegas-toys-par...
Ты ARC4 видишь? А он есть. И даже умеет DMA в системную память. Такая фигня :)
> Тысячи. В Core2Duo было не менее 2000. Крис демонстрировал удаленной взлом компьютера
> с таким процессором с любой операционной системой, хоть freedos.Небось ещё и через сгоревший Ethernet при отсутствующем AMT?..
Нафига такие сложности? Просто через провод 220.
> при отсутствующем AMT?..А нынче BMC контроллер есть почти в любом ноуте и прочая. Кроме всего прочего он еще динамическую скорость вращения вентиля обеспечивает и тому подобные плюшки. Как я понимаю отличие только в том какое фирмваре и как оно себя ведет. Разумеется фирмваре проприетарное до мозга костей и что оно там делает - мало кто знает.
> А нынче BMC контроллер есть почти в любом ноуте и прочая.Прям-таки BMC? И в том, что под руками, он отключен (не факт, что снятый крыжик *действительно* отключает *полностью* функциональность удалённого управления, но это немного другой вопрос).
> Кроме всего прочего он еще динамическую скорость вращения вентиля обеспечивает
> и тому подобные плюшки.В thinkpad этим EC занимается. Наружу он, насколько мне известно, никак не вывешен, всё управление через SMAPI.
> Прям-таки BMC?Прям таки он самый. В ноутах он всякими режимами питания еще рулит и прочая. Нынче всякие там контроллеры заряда аккумуляторов, преобразователи питания и прочая - весьма интеллектуальные штуки. Их после включения питания надо программировать. Вот и возникла нужда в вспомогательном проце. Интел встроил его прямо в чипсет.
> И в том, что под руками, он отключен
Он полностью не отключается никогда, потому что при этом управление вентилятором отпало бы. Крыжик в биосе лишь информирует фирмварь BMC о том что ей надо прикинуться шлангом. Насколько честно оно это делает - вопрос интересный.
> (не факт, что снятый крыжик *действительно* отключает *полностью*
> функциональность удалённого управления, но это немного другой вопрос).Вот именно: кусок проприетарного нечто. Интель даже документацию на систему команд этого проца снес. Насколько оно не врет - предлагается верить на слово. В свете того как MS лихо подписал тулкит для промышленного шпионажа - ну верьте, только не говорите что не предупреждали.
> В thinkpad этим EC занимается. Наружу он, насколько мне известно, никак
> не вывешен, всё управление через SMAPI.Раньше такой контроллер был отдельно, но в куче современных ноутов этим занимается проц встроенный прямо в чипсет. Он же и ремотное управление обеспечивает, если соотв. кусок фирмвари есть. Как я понимаю, он один на все у интеля. Технически у него есть доступ вообще везде. И в сеть в частности. Со стороны х86 к процу и его фирмвари доступ основательно порубан, вплоть до того что чипсет виртуализует доступ к SPI-флешке, показывая х86 процу только образ BIOS. Хотя физически в чипе живет не только BIOS но и фирмвара этого проца и интелского гигабитного эзернета (если он есть). Причины по которым оно вот так - понятны, но вот то что у этой штуки есть неограниченная возможность шариться по х86 части - совсем не айс. Собственно, это и позволяет при должной фирмвари ремотное управление. Только вот фича обоюдоострая. ИМХО, по уму должна быть возможность сбилдить сие из сорца на который смотрит толпа народа и зашить заведомо проверенную версию. А не черт знает какой блоб делающий хрен знает что.
> Крис демонстрировалв своих влажных мечтах.
> в своих влажных мечтах.И тем не менее, почитай просто даташит на чипсет интеля - и ты поймешь что половина влажных мечт всего лишь обыденная реальность.
Qubes - это и есть упрощение. Суть системы в том, что главная точка отказа там переносится с ядра на гипервизор, который намного проще.
> Qubes - это и есть упрощение. Суть системы в том, что главная
> точка отказа там переносится с ядра на гипервизор, который намного проще.Qubes это вообще по сути очень странная реализация микроядра. Где арбитром ресурсов выступает гипервизор, а вместо просто процессов - метапроцессы-операционки. Несколько переусложнено и ресурсожорко. Зато концепт лепится из того что есть и работает. Тогда как труЪ микроядра не могут осилить в нормальном виде уж лет 20.
Осилить-то могут, внедрить не могут.
ёще одня уязвимость нулевого уровня, позволяющая побег из виртуальной машины?)))
Статью не читай @ пиши в комментах.
"Сбежать" из виртуальной машины может только администратор, имеющий доступ к консоли. Т.е. в случае Qubes - тот, кто имеет доступ к хост-системе. Гости же к своему qemu monitor-у доступа не имеют.
>> A guest administrator who is granted access to the graphical console
>> of a Xen guest can access the qemu monitor. The monitor can be used
>> to access host resources.Оригинал не читай, свои домыслы авторитетно в комментах оставляй...
пост не читай, а сразу отвечай. C чего вы взяли, что в Qubes гостевые окружения имеют доступ к графической консоли qemu?
> пост не читай, а сразу отвечай. C чего вы взяли, что в
> Qubes гостевые окружения имеют доступ к графической консоли qemu?А с чего вы взяли, что гостевые окружения должны иметь доступ к консоли qemu в в том же libvirt??? Проблема как-раз в том, что он у них есть, хотя его быть не должно.
предыдущий аноним, в поддержку которого я выступил, утверждал об отсутствии доступа к графической консоли гостевых окружениях Qubes (с вашим уточнением - посредством libvirt). Но есть ли в гостевых окружениях Qubes libvirt? Зачем она там?
Да, уязвимость есть, если правильно настроить окружение для ее эксплуатации. но пост был не об этом.
Так что, читайте прежде чем писать
> предыдущий аноним, в поддержку которого я выступил, утверждал об отсутствии доступа к
> графической консоли гостевых окружениях Qubes (с вашим уточнением - посредством libvirt).
> Но есть ли в гостевых окружениях Qubes libvirt? Зачем она там?
> Да, уязвимость есть, если правильно настроить окружение для ее эксплуатации. но пост
> был не об этом.
> Так что, читайте прежде чем писатьЯ не имел ввиду, что в Qubes есть libvirt. Я как-раз имел ввиду, что уязвимость затрагивает Xen ниже уровня самой графической консоли, так как libvirt стороннее приложение по отношению к собственно Xen.
Это уязвимость не xen, а в qemu. xen она затрагивает только косвенно.
Фанаты Xen любят хвалиться маленьким размером кода, который якобы позволяет писать секурный гипервизор. А на деле, когда последний раз находили уязвимости в KVM? Кстати, в Xen 4.1.3 было исправленно 4 уязвимости.
> Фанаты Xen любят хвалиться маленьким размером кода, который якобы позволяет писать секурный
> гипервизор. А на деле, когда последний раз находили уязвимости в KVM?
> Кстати, в Xen 4.1.3 было исправленно 4 уязвимости.А в KVM код большой? Там даже superOS нет. Только модуль ядра. Всё остальное обвязка для управления им.
> А в KVM код большой? Там даже superOS нет. Только модуль ядра.Дык модуль ядра + это самое ядро. Ну и все его баги.
>> А в KVM код большой? Там даже superOS нет. Только модуль ядра.
> Дык модуль ядра + это самое ядро. Ну и все его баги.Дык Xen + тот самый Dom0. И все его баги. И не говорите, что гипервизор, он отдельно. В нулевом кольце "отдельно" не бывает.
> говорите, что гипервизор, он отдельно. В нулевом кольце "отдельно" не бывает.Зато нынче бывает "ring -1". Специально для гипервизоров. А вы думали что ring 0 всемогущий? Вас обманули, там нынче бывает еще 1-2 уровня. Добро пожаловать в матрицу - то что вы видите не обязано быть тем чем на самом деле является :)
> А в KVM код большой?Огромный. Гипервизором выступает вся ядро хоста.
>> А в KVM код большой?
> Огромный. Гипервизором выступает вся ядро хоста.А xen уже научился "летать" без Dom0??? Гипервизор или модуль тут не важно. И то и то крутится в кольце 0...
> А xen уже научился "летать" без Dom0???Тут интереснее скорее то, что является наиболее привилегированным кодом с полным доступом ко всем ресурсам железного хоста и кто производит арбитраж доступа к ресурсам. Заметьте, у рутковской в системе драйвера делающие I/O с реальным железом вообще вынесены в отдельный гуест, а dom0 достаточно обкоцан :). Чем-то напоминает микроядра, только вместо микроядра гипервизор, а вместо задач - гуест-операционки.
FTGJ: по крайней мере в последней новости было не о написании, а о аудите, и тут сложно поспорить.
Количество найденных уязвимостей ничего не говорит о безопасности системы, а только об отношении активности работы над ней к ее сложности.
Говорит = (Количество найденных / количество исправленных уязвимостей) * срок исправления
> Количество найденных уязвимостей ничего не говорит о безопасности системы, а только об
> отношении активности работы над ней к ее сложности.На эту тему лучше всего почитать статьи разработчиков openbsd. На безопасность системы сказывается даже стиль программирования. "Чёткий потчерк" даёт меньше ошибок и облегчает поддержку. "Как курица лапой"... Вот сейчас сижу и "радуюсь", такому исходнику. Благо он маленький. Чувствую, что проще будет самому заного написать...
> Фанаты Xen любят хвалиться маленьким размером кода, который якобы позволяет писать секурный
> гипервизор. А на деле, когда последний раз находили уязвимости в KVM?
> Кстати, в Xen 4.1.3 было исправленно 4 уязвимости.Ошибка в теме новости относится к qemu.
Для того, чтобы её закрыть в Xen, нужно добавить одну строчку в конфиг.
> Фанаты Xen любят хвалиться маленьким размером кода, который якобы позволяет писать секурный гипервизор.Все так.
И сабжевая дыра только подтверждает это правило - она не в xen, а в qemu.
> Фанаты Xen любят хвалиться маленьким размером кода, который якобы позволяет писать секурный гипервизор. А на деле, когда последний раз находили уязвимости в KVM?Вы так говорите, как будто KVM не QEMU использует. А дыра-то как раз в QEMU.
>> Фанаты Xen любят хвалиться маленьким размером кода, который якобы позволяет писать секурный гипервизор. А на деле, когда последний раз находили уязвимости в KVM?
> Вы так говорите, как будто KVM не QEMU использует. А дыра-то как
> раз в QEMU.КVM QEMU не использует. У них часть кодовой базы (значительная, не спорю) сейчас общая, но один реализует HVM, а второй бинарную эмуляцию. Две части одного целого. Но похоже эта функция в них реализована разным кодом (хоть это и странно несколько).
> КVM QEMU не использует.Использует. Учите матчасть.
> У них часть кодовой базы (значительная, не спорю) сейчас общая, но один реализует HVM, а второй бинарную эмуляцию.
Что за бред?
> КVM QEMU не использует.Кто вам такую глупость сказал?
То есть попросту стандартную фичу с консолью в vnc не отключили?
> То есть попросту стандартную фичу с консолью в vnc не отключили?Собственно, да. И почему-то додумались до того, что это уязвимость, только сейчас.
Капитан Очевидность крепко спал, видимо.
На третий день Зоркий Глаз заметил что у сарая нет стены...
Ужас, какая ксенофобия в форуме. :-)
> Ужас, какая ксенофобия в форуме. :-)Особенно к фантомасам в резиновых масках! :)
Press CTRL+ALT+2 to pwn hypervisor. Хм. Такое надо прямо стандартное приглашение системы записывать :)