Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Virtual Machine Detection in the Browser (2019)

bannedit.github.io

Post reply on HN
Print view View original

81–90 of 98 posts

Re: Virtual Machine Detection in the Browser (2019)

#81

Post by tenebrisalietum »

userbinator wrote: post #2

quickly realized that some of the fingerprinting information could be useful for VM detection because vendor names were exposed. In this particular instance the string "VMWare" was contained within the WebGL information. After some more testing I also discovered that VirtualBox reported the same kind of information. I believe there are patches that can close those holes, but I've always found the fact that such infor…

> Ideally, a VM should be indistinguishable from real hardware

VMs wouldn't achieve the performance they do without paravirtualization. VMs don't meticulously emulate all attached virtual devices. Paravirtualized device drivers more or less forward the I/O request to the hypervisor which handles it in a VM-specific way. For example, it's not super useful for a VM to emulate all the bitwise register-twiddling dances needed to talk to a SATA controller, it can simply have some "backdoor" channel into the hypervisor that says "Queue request to write X to LBA Y for this VM".

Since paravirtualization requires specific drivers, it will always be detected.

Re: Virtual Machine Detection in the Browser (2019)

#82

Post by Wowfunhappy »

pksebben wrote: post #64
tomaszs wrote: post #44

Earlier quoted context omitted.

The problem with limiting browser features is that it makes web apps less competitive with apps on propertiary platforms. I agree not all websites should have access to battery API, but the user should decide on that, not a browser vendor. The same goes for all other limitations imposed.

I think the sane argument here is for sensible defaults. Leaving all those switches turned on is just opening the door for adtech. The set of information that's made available out of the box should be small, and if you need to access information about my graphics card, you can ask for it.

I think this only works if the average consumer can assess what is being asked for, though. “Do you want to let this website know what hardware you have?” is not a simple question.

“What is hardware?”

“Should I let a game know my hardware? Should I let a news website know my hardware?”

Re: Virtual Machine Detection in the Browser (2019)

#83

Post by Wowfunhappy »

elcomet wrote: post #43
Wowfunhappy wrote: post #7

Earlier quoted context omitted.

...no, that's where I don't agree. Again, software should attempt to be truthful by default. There's a reason we allow programs to detect the hardware they're running on—it allows for all sorts of optimizations. Does the VM claim it's network driver was manufactured by Broadcom, or does it go with Cambridge Silicon Radio? Or does it decline to provide a vendor, and if it does, how long until software starts assuming…

It could report the host's hardware.

But now you're leaking information about the host, which I would think is worse given the purpose of a VM.

Re: Virtual Machine Detection in the Browser (2019)

#84

Post by jmnicolas »

gruez wrote: post #78
jmnicolas wrote: post #55

Earlier quoted context omitted.

I tried it, it's highly inconvenient. Maybe QubesOS would help, not sure.

That wouldn't really help. The containers/VMs might be separated from each other, but they're running on the same hardware/software stack, so they'll behave the same should you decide to fingerprint it.

I meant for convenience since launching VM is part of the OS.

Wouldn't every Qubes VM (whatever the underlying physical machine) return the same fingerprint? Something like VM Fedora version XXX running on Xen hypervisor.

Re: Virtual Machine Detection in the Browser (2019)

#85

Post by kaashmonee »

twelvechairs wrote: post #56
userbinator wrote: post #2

quickly realized that some of the fingerprinting information could be useful for VM detection because vendor names were exposed. In this particular instance the string "VMWare" was contained within the WebGL information. After some more testing I also discovered that VirtualBox reported the same kind of information. I believe there are patches that can close those holes, but I've always found the fact that such infor…

> JS needs to be off by default and whitelisted only for the (very few) sites that one truly trusts. Or the information provided by JS regarding the local machine should be reduced

I feel like this might be a better and more feasible solution. Is there a reason that JS can collect as much data as it does about our hardware? I feel like I always hear the mantra, "The browser is a sandbox," but reading articles like this make me really unconfident that that is true. I don't really have too much of an idea of how WebGL works, but I wonder if there's a way to create some sort of additional abstraction layer between a website and the hardware? So JS just has access to "hardware interfaces" like a CPU and a GPU but can only interact with via this interface. That way, even if a site wanted to, the best it could do is determine that your computer has a GPU or a CPU but not how many cores or what type of GPU?

This would however have the downside of incurring an additional latency with an additional abstraction, but if there was a way you turn this off with trusted websites and only leave it on when you're using a site you don't trust it could be more usable? It just seems better than disabling JS entirely since a lot of websites just completely break without JS.

It just seems like with the amount of information that JS can collect, even if you're using TOR or a VPN, if you crunch all the information about a particular user, like the kind of OS they're running, the version of the browser, the screen ratio, mouse click movements, time of access, number of CPU cores, type of GPU, whether or not it's a VM, etc., it just feels like you might be able to devise a pretty reasonable heuristic for where this person is and the kind of computer they're using. I can't really say I know the extent of browser and JS capabilities, but these things already seem alarming enough where I wouldn't really feel super confident that I can't be tracked even with TOR or a VPN.

Edit: Just discovered something similar to this is being worked on already! https://gpuweb.github.io/gpuweb/#malicious-use

Re: Virtual Machine Detection in the Browser (2019)

#86

Post by ruslanbogan »

elcomet wrote: post #43
Wowfunhappy wrote: post #7

Earlier quoted context omitted.

...no, that's where I don't agree. Again, software should attempt to be truthful by default. There's a reason we allow programs to detect the hardware they're running on—it allows for all sorts of optimizations. Does the VM claim it's network driver was manufactured by Broadcom, or does it go with Cambridge Silicon Radio? Or does it decline to provide a vendor, and if it does, how long until software starts assuming…

It could report the host's hardware.

It would have to emulate the host hardware to do that because the fingerprint is only going to report what's listed in Device Manager for instance.

Re: Virtual Machine Detection in the Browser (2019)

#87

Post by bob1029 »

userbinator wrote: post #2

quickly realized that some of the fingerprinting information could be useful for VM detection because vendor names were exposed. In this particular instance the string "VMWare" was contained within the WebGL information. After some more testing I also discovered that VirtualBox reported the same kind of information. I believe there are patches that can close those holes, but I've always found the fact that such infor…

For timing based attacks, couldn't we start looking at injecting random jitter into the JS runtime? You could source the timing entropy from a CSPRNG so that attackers would be unable to distinguish from random noise. Obviously, this would have an impact on performance, but it could be something that is controlled on a per-host basis as required.

Re: Virtual Machine Detection in the Browser (2019)

#88

Post by Jonnax »

gruez wrote: post #80
Jonnax wrote: post #67

The fact that browsers allow websites to see whatgpu you have installed, driver version and enumerate your fonts is clearly put there for the benefit of tracking people. Otherwise browser developers would create generic classes of device that segment users into large groups based on features. The fonts thing is proof. For years, you install a custom font on your pc. Then you are unique.

Not really. Some GPU/driver implementations are simply broken, and can't be trivially detected via feature detection. That's why gpu blacklists are a thing https://wiki.mozilla.org/Blocklisting/Blocked_Graphics_Drive... .

The website doesn't need to blacklist it, the browser can do that.

Re: Virtual Machine Detection in the Browser (2019)

#89

Post by tomaszs »

Wowfunhappy wrote: post #82
pksebben wrote: post #64

Earlier quoted context omitted.

I think the sane argument here is for sensible defaults. Leaving all those switches turned on is just opening the door for adtech. The set of information that's made available out of the box should be small, and if you need to access information about my graphics card, you can ask for it.

I think this only works if the average consumer can assess what is being asked for, though. “Do you want to let this website know what hardware you have?” is not a simple question. “What is hardware?” “Should I let a game know my hardware? Should I let a news website know my hardware?”

It is a discussion how to do it right. And surely, if propertiary platforms can do it, browsers can do it too. Especially propertiary platform app has permission to the system data enabled on default. Browser asking for it, would make web apps safer than native ones

Re: Virtual Machine Detection in the Browser (2019)

#90

Post by gruez »

Jonnax wrote: post #88
gruez wrote: post #80

Earlier quoted context omitted.

Not really. Some GPU/driver implementations are simply broken, and can't be trivially detected via feature detection. That's why gpu blacklists are a thing https://wiki.mozilla.org/Blocklisting/Blocked_Graphics_Drive... .

The website doesn't need to blacklist it, the browser can do that.

And what if it only crashes/breaks on certain operations?
Post reply on HN