id: Гость   вход   регистрация
текущее время 13:39 27/06/2017
Автор темы: 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)   профиль/связь   <#>
комментариев: 411   документов: 5   редакций: 9

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


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.
На страницу: 1, 2, 3 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3