Security Vulnerability in Browser Interface Allows Computer Access via GPU
tugraz.at
tugraz.at
that suggestion isn't even viable on Tor websites
At work I run a hardened browser that disables a hell of a lot more than JS and not only do most pages work just fine as far as providing the content I wanted from them, but they load faster and look cleaner. There are still some annoying cases when a website can't even manage to display text or images without JS enabled, but even as easy as it is to enable JS if a website is that broken I often just close that tab and move on with my life anyway. I don't use that browser for things like online shopping but for 90% of what I need it works while also being far better for security and privacy
A surprising number of sites work, at least well enough, with JS disabled. When they don't I can selectively enable JS as needed until I get the functionality required. Often that is a single permission or two, while I keep everything else disabled.
If you're willing to dedicate the troubleshooting time to your web experience you can get yourself into a pretty useable state over time though.
i use uBlockOrigin for ad block. it have a setting "disable js". done.
each site you visit either works... or you leave it. if you must use it and it's a blank page, press ctrl+e, or open the ad blocker UI (works even on Firefox Android) and uncheck the blocked js icon. again, done. two clicks or one keyboard shortcut.
and as the comment your replying to said, you will be surprised how everything works fine without
Also if you just whitelist every site the instant they don't work it's not exactly a security gain. Maybe it helps with ads UBO isn't catching out of the box or some other angle though. The amount of security you gain from this is proportional to the amount of effort you're willing to invest in making sites work. As an example: https://news.ycombinator.com/item?id=40069834 site works fine without one day, then suddenly doesn't so you whitelist or futz around until you find something like the /embed trick, until that either changes some day too or you've given up and just whitelisted every site you go to anyways.
you seen to spend time here, so you'd pay the security price and that's it.
not having js on by default is for the 95pct of domains you hit everyday to read a single paragraph and never return.
I hear they are working on even more APIs for TheWeb(tm).
https://www.yubico.com/support/security-advisories/ysa-2018-...
WebAuthn/U2F is not designed for this. As it usually happens in tech, people hack weird contraptions afterwards (largeBlob, prf and hmac-secret) allowing to at least attach or derive the symmetric keys, but this isn't a solution even if it would've worked.
I can setup a (macOS) VM and expose the web IDE securely to myself, but I wasn’t able to find a working solution about a year ago.
The closest solution for me right now is using Google’s IDE ‘IDX’, basically a web VSCode with a right side panel containing an actual Android/iOS emulator. It’s neat, but I’d rather use my physical devices over USB during development.
PS. If anyone knows how to set this up, please share!
A native Android app isn’t more secure than a web page running on that device, and the champions of Open Web Apps need the same hardware access privileges as native apps have in order to be a viable competing platform for development.
HN is very strongly in favor of OWAs, so it’s confusing to see hostility to hardware access by webpages here? How else could a firmware updater app work?
Made me look.
Chrome engineer: Hold my beer!
*Not supported on Safari, thank goodness!
I lol'd at that one. No one would never make such a thing... Wait would they?!?!
I can hear it now: millions of non-solid-state drives across the Internet playing the Imperial March in sync...
> Like earlier, we assume our attacker embeds some malicious JavaScript in a webpage the victim is browsing for several minutes. The vic- tim runs a GPU-based AES implementation that can be queried for encryption with a chosen plaintext and key.
Nobody runs a GPU-based AES implementation, so I feel the thread model and thus the assumptions of the paper are on a quite shaky ground.
This attack is not wholly different from them saying “we made an aes implementation on the gpu and it leaked timing information”, yes it’s technically present, but the problem is not that you can’t tell the gpu to disable any predictors or caches, it’s that you’re using a wholly unsuited tool for a wholly inappropriate task with known hazards and expecting different outcome.
The explicit anti-feature is the ability to do yet another side-channel attack. Also out-of-spec is the incredibly power-inefficient IPC mechanism. And I doubt a probabilistic querying of what kind of code the rest of the system is running was ever part of the spec either.
> The team was able to track changes in the cache by filling it themselves using code in the JavaScript via WebGPU and monitoring when their own data was removed from the cache by input. This made it possible to analyse the keystrokes relatively quickly and accurately. By segmenting the cache more finely, the researchers were also able to use a second attack to set up their own secret communication channel, in which filled and unfilled cache segments served as zeros and ones and thus as the basis for binary code. They used 1024 of these cache segments and achieved transfer speeds of up to 10.9 kilobytes per second, which was fast enough to transfer simple information. Attackers can use this channel to extract data that they were able to attain using other attacks in areas of the computer that are disconnected from the internet.
I don't understand which cache they're talking about, and why this has anything to do with keystrokes. And suggesting the use of cache invalidation to transmit information from one process to the browser doesn't really sound like a very concerning attack vector (how did you get a process running on the host computer in the first place, but without Internet access?)
> The third attack targeted AES encryption, which is used to encrypt documents, connections and servers. Here, too, they filled up the cache, but with their own AES encryption. The reaction of the cache enabled them to identify the places in the system that are responsible for encryption and access the keys of the attacked system.
Sorry, what? No part of this tracks for me. Who is even using the GPU for AES encryption? Or is this looking at the CPU cache by way of webgpu?
If there's good work being done here, this article is frankly doing it a massive disservice.
It looks like it targets AES and keystrokes if they're processed on the GPU. They detect which parts of AES lookup tables (T-Tables) are getting added to the cache, which gives information about the key (section 6).
> Despite the high recall, with the low precision, we can consider this attack mostly failed or severely degraded
And in to what I said originally (who is actually doing AES on a GPU?) it sounds like the key recovery is also impractical:
> In order to implement a last-round attack, we assume the attacker has access to the victim’s ciphertexts, but not the plaintext or the key.
How exactly is a browser supposed to get access to the ciphertext in the first place?
MITM attacks are usually considered relatively easy to pull off. Run a fake wifi-hotspot in an airport, use the "login portal" to get access to their browser, use the hotspot itself to get access to the cipher texts when they visit other https page (edit: I suppose those would be decrypted on the CPU... but when they use whatever odd program that thought decrypting messages to it on the GPU is a good idea).
It's obvious they accomplished something, but the scenario they set up simply isn't something that is practical in the real world
Modern CPUs can decrypt AES with specialized instructions at a rate that's practically measured in GB/s. Especially for streaming video that doesn't need to decrypt the full stream at once (and where you're probably already using the GPU to, you know, render the video) why would you use the GPU for AES?
Even then, the best that I know of for password recovery from timing is "Timing Analysis of Keystrokes and Timing Attacks on SSH", which relies on having data about the user in advance, and they only manage to reduce the search space by about 50x. I'm sure the state of the art is probably a bit better, but that's still assuming a lot: key press timing (that's probably noisy) isn't going to be a meaningful attack vector for arbitrary users online.
that said, I don't expect to see any of these attacks in the wild. they're primarily demonstrations of the technique and to show that the channel is there
as is often the case with side-channel attacks, a serious attacker would much more likely go for un-/recently patched traditional vulnerabilities
We tried to walk the line between enough information and not overwhelming, but it doesn't always work out :D Luckily there's always the paper.
This article also did a pretty good job of a high-level summary imo https://www.securityweek.com/new-attack-shows-risks-of-brows...
If they can’t, this is fud