id: Гость   вход   регистрация
текущее время 19:06 28/03/2024
Автор темы: jack3d, тема открыта 31/05/2016 21:42 Печать
Категории: софт, анонимность, приватность, инфобезопасность, уязвимости, операционные системы
http://www.pgpru.com/Форум/ПрактическаяБезопасность/КакиеДанныеОМоемРеальномЖелезеЗнаетVirtualBox
создать
просмотр
ссылки

Какие данные о моем реальном железе знает VirtualBox?


Всем привет. Касательно своего вопроса я много информации прочитал, много мнений послушал + с разрабами тоже пообщался, но все же решил послушать спецов в этом деле. Лишним не будет точно!


Есть ноутбук. На котором стоит в качестве хоста kali linux. В качестве гостевой стоит whonix на virtualbox.


Вопрос следующий:


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


(про мак-адресс можно не писать)


 
На страницу: 1, 2, 3 След.
Комментарии
— Гость_ (23/11/2016 23:41, исправлен 23/11/2016 23:43)   профиль/связь   <#>
комментариев: 450   документов: 10   редакций: 13

Длинная дискуссия в рассылке на тему того, что и как с этим делать:


Joanna Rutkowska:


I haven't played with it, but see no reasons it should not work. I can imagine we introduce a prefs for VMs (say "generic_cpuid" settable via qvm-prefs) that would be resulting in additional config for cpuid emulation inserted in the config file for such VMs. We would need to agree on good-enough-for-everybody CPUID config and stick to it then. Again, this would be use-able for anon VMs mostly.

However, this will not work for PV VMs, because the CPUID instruction is not a privileged instruction, so malware in a PV VM can always execute this instruction (even if we hooked Xen interface for CPUID-like info to the guest) without trapping into XEN in PV operation.


AFAIU, there are not personal identifying info returned by CPUID, but I can see how this could be used as an additional fingerprinting vector. Thus, perhaps we should consider distributing Whonix workstation template as an HVM template instead of a PVM one? Fortunately we do have templates support for HVMs, so this should be perfectly possible.


However, this will not work for PV VMs, because the CPUID instruction is not a privileged instruction, so malware in a PV VM can always execute this instruction (even if we hooked Xen interface for CPUID-like info to the guest) without trapping into XEN in PV operation.

That's too bad for excluding paravirtualized VMs.

BTW, it should be obvious, but let me point out that any compartmentalizing technology for x86 that is not based on VT-x/AMD-v would be prone to this problem. This is b/c CPUID is an instruction and its execution cannot otherwise be controlled by the OS, other than via VT-x intercept.


A big part of the problem here is that so few people are using Qubes + Whonix, that if 2 AnonVMs got trivially popped (via Firefox, Thunderbird, PDF, IMG, etc) and had the same CPU specs, it would no doubt predictably be the same user/person out in the world using that instance of Qubes + Whonix, since there are probably many more CPU models than such users at this point.


And if there is any personally identifying info/documents/etc inside one of the VMs, then it's a true identity game over for all known AnonVM activity simply tied back to a CPU model.


With GOV netflow and other vast personal activity history, such as technology purchases, software statistics/debug uploads, Qubes HCL report contributions, etc, it only gets easier to filter out key information and potentially infer identity based on 1 single AnonVM compromise.


I'm guessing that this would not limit the speed of the CPU(s) that the HVM is exposed to? Just changes the info/attributes of the AnonVM domain's CPU (including reported MHz?)?

No.
— unknsecured (04/10/2018 14:38)   профиль/связь   <#>
комментариев: 17   документов: 1   редакций: 2
Напишу сюда, чтобы не плодить темы. Посмотрел VirtualBox и заметил несколько неприятных моментов: Кроме уже упомянутой непонятно зачем допущеной разработчиками утечки параметра процессора, утекает и DNS! Я считаю это серьезная уязвимость! Как можно сделать чтобы для VirtualBox DNS был недоступен всегда (как при пустом resolv.conf)?
И общий вопрос: насколько там защищена сеть внутри VirtualBox? То есть когда сеть поднята и доступна одной группе ОС, а в другой, если выключено в конфиге, то реально отрублено без случайных утечек! Тот же вопрос касается маршрутизации, поднимаемой в пределах VirtualBox (как с Whonix).
— Гость_ (12/03/2019 16:55)   профиль/связь   <#>
комментариев: 450   документов: 10   редакций: 13
Намучался я с VB! Кроме упомянутого слива проца, издевается через мышь: Захватывает управление, так что указатель двигается и в хостовой ОС, но кликать можно только в окне какой-то конкретной запущенной в виртуалке ОС. Еще через какое-то время работы фокус указателя мыши сдвигается примерно на размер одного указателя (стрелки) выше. То есть, если, например ткнуть на текст, то курсор окажется строкой выше, хотя, еще раз: указатель ниже! При этом, настройки в закладке мыши (PS2,USB,планшет) никак на этот глюк не влияют(

Ну и кроме этого, как-то странно распределяет ресурсы: На досточно мощном компе, сжирает все! Независимо от процентных полозков ресурсов проца и количества процов. Еще через каждые десять раз запущенные в виртуалке ОС сами по себе вылетают (не закрывается окно, а запущенная ОС либо мертво виснет, либо в этом же окне перезагружается или перезапускается интерфейс).

Я так понимаю, что сама структура виртуалок такова, что этот софт (VB, другие) использует готовые модули в ядре? Такие как: QEMU/KDM и т.п.? А можно ли как-то научиться запускать под этими модулями ОС буквально из консоли? Или может есть какой более легкий (по глюкам) аналог VB?
На страницу: 1, 2, 3 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3