4 ms·
1. It won't take long for this attack to stop being "theoretical" (assuming it still is). 2. No one has to target you specifically, it's a matter of time until
by iooi 9y ago
1. It won't take long for this attack to stop being "theoretical" (assuming it still is).
2. No one has to target you specifically, it's a matter of time until someone uses this attack vector on something everyone has -- a web browser.
3. Once you're owned, you're going to be sharing resources with a couple of bots, so don't be so sure you'll get to keep the performance.
- joosters 9y agoWeb browsers are potentially easier to protect, as I understand it. You prevent javascript from getting access to high accuracy timers and rate-limit their access to syscalls. If a script is repeatedly calling methods that trigger a syscall thousands of times a second, just slow it down a little and the attack becomes impossible.
- deleted 9y ago[deleted]
- mort96 9y agoDisabling high precision timers isn't a long term solution. There's probably only a matter of time until someone finds a new way to make a high enough precision timer, and even if that wasn't the case, features like SharedArrayBuffer are just too useful to completely disable forever - and there's no easy way to make it impossible to create a high precision timer with a SharedArrayBuffer (just have a web worker which just increments a number in a shared buffer in a loop). Would throttling syscalls really prevent using these syscalls? Surely it would just make the exploits lower to perform? Is there something I've not understood, or is the idea just to throttle syscalls enough to make it infeasably slow? If it's the latter, remember that users might potentially be on a website for half an hour at a time (if they're reading a long article or watching a video), so an attacker (whose code is running on the site, potentially through a compromised ad/tracking platform, or just XSS) would have a lot of time to extract whatever memory they want.
- wtallis 9y ago> and even if that wasn't the case, features like SharedArrayBuffer are just too useful to completely disable forever That's only if you continue to participate in the shared delusion that the WWW can or should be a high-performance applications platform. Those of us who usually browse with JavaScript turned off can get along fine without SharedArrayBuffer or WebGL or WebSockets.
- LaGrange 9y agoBut how will you mine bitcoin or whatever for your favourite website then? /grumble
- crysin 9y agoHonestly curious, why is it a delusion to want the WWW to be a more powerful platform that offers more than just being a web of shared documents? Why is it bad for there to be an array of purposes or applications available on the Web? Just because you don't see value in it, doesn't really make it fair to call others who do see value in it delusional.
- wtallis 9y agoThe WWW started out as a document sharing platform, and that has proven repeatedly to be a horrible base upon which to build an application platform. There's technological ugliness in the form of kludges like WebAssembly and WebSockets and WebGL that are (badly) re-inventing large parts of the operating system. There's the usability nightmares caused by trying to make a web application imitate a native UI (or worse, trying to use web technologies locally as a UI toolkit a la Electron). The addition of application-oriented features has detracted from the original feature set: gratuitous overuse of JS for stuff that can be done in CSS and HTML is rampant, leading to less responsive sites with worse accessibility and worse battery life. And sooner or later, every attempt to shoehorn a real security model onto the Web has fallen. Every month, the idea of a secure sandbox for running untrusted third-party code looks more and more like a pipe dream. I fully understand how much the world has invested in making the web into an applications platform, and I recognize that many things of value have been built on that platform. But it's been a fundamentally flawed enterprise from the start, and the pitfalls are getting harder to ignore. We need to start taking seriously again the idea that untrusted code cannot be trusted. We need to stop re-inventing the operating system within the browser just because some programmers are too lazy to port their applications to more than one OS even when there are libraries to abstract away all the differences that don't require a UI redesign. We need to stop sacrificing so much efficiency for the sake of portability that doesn't live up to its purpose. In order for a web browser suitable for document-oriented usage with limited interactivity to be secure and offer reasonable protections for your privacy, it has to take measures that preclude it from being a good applications platform. That conflict seems irreconcilable.
- delbel 9y agoI read there is already a web browser exploit, if I remember it was a CCC talk this summer
- earenndil 9y agoAll OSes will be patched soon and then no one will be attacking using this exploit anymore.
- ivanbakel 9y agoPlenty of legacy OSes will not receive any patches, plenty of current OS instances will not be updated by technically incompetent owners, and either way attacks using this exploit will continue to be profitable.
- dagss 9y agoServers don't have/need web browsers (in general). Some on premise compute clusters don't even necesarrily have internet access except SSH from a few trusted users and exploits to run code locally would go through them or SSH (at which point you don't need meltdown to access the data). I believe there are valid usecases for not applying these patchws.