It appears to be very difficult to take advantage of, and the initial idea of a JavaScript exploit seems to not be possible.
Part of the reason for all of this might be that the attacker needs to run code on the target machine, and one the attacker can do that, there are far easier ways to read memory.
However, just being able to read all of kernelspace is more of a force-multiplier than being useful on its own. You still need to get your code executing in user-space to do anything, ant it's value even then is at least partly tied up in its ability to easily defeat KASLR.
Also, meltdown requires the data to be snooped to be in L1D cache. So the current demo exploit has to keep pushing the data into cache to be read.
Something simple like steal a password from sudo should be trivia right? I'd not convinced i need to worry.
And making non public facing machines pay the price of the mitigation seems like too much.
Thanks, but no thanks, do not want.
- cookies (e.g., for online banking sessions)
- keys (e.g., for pushing to git repos)
- browser history
- identities (oh, did you post anonymously somewhere?)
- ...
PoC code that runs in-browser exists. It's only a matter of time before it's weaponized.And even the whitepaper doesn't have a working js exploit of spectre, just a couple pieces and some assumptions.
One of many source codes online and they are actually pretty understandable by me. I am just a mediocre c programmer.
Like i said:
- JavaScript appears to not be a possible attack vector. So now we're just worried about already had access to run a native binary.
- so a native program that sat snooping sudo passwords would be a good demo, but obviously if a rogue binary had to sit running for days with only a part success rate, we would be able to attack stupid managers and evil corporations because it wouldn't be very impressive. If I'm already running binary code, i have a lot of better ways to attack the system.
> JavaScript appears to not be a possible attack vector. So now we're just worried about already had access to run a native binary.
All the major browsers have pushed patches, to close this, because it was a gaping hole. You're only not worried, because they've already fixed it. (Well, when I say major browsers, I haven't seen or heard anything from Microsoft's Chakra engine.)
Take note that it involved killing off SharedArrayBuffer in JS, at least for now.
> but obviously if a rogue binary had to sit running for days with only a part success rate
That's misreading the situation.
A tight loop is required, yes, with partial failure, but it is not so low as taking days. The original implementation [0], read at around 10KB/s. Whilst that isn't fast if you're somehow trying to read gigabytes of data into cache, and then attack it, it's more than enough to read passwords out of data.
> So now we're just worried about already had access to run a native binary.
Now we're worried about any unpatched JavaScript engine, like perhaps Chakra, which would make all Edge users vulnerable.
You also don't need access to an executable binary. You could also target any DLL that gets dynamically linked on Windows. In fact, the example Windows implementation hooks into ntdll.dll, which has a known location on all versions of Windows, which allows it to bypass ASLR.
Maybe that would shed some light on who needs to worry and why.
I'm surprised the js jit writers have escaped with so little blame for Spectre since in the end it is basically just a process reading its own address space (I'm actually surprised more of these vulnerabilities don't exist since things like proc/dev/run are ripe for abuse).
I think it is useful to know that these exploits just might not be as bad as they are being made out to be.
Ice talked to a number of people that don't seem to understand that there are limits on these: somebody cant just start reading data from random programs.
But as I've learned more about how this community works, I understand that "Why does HN [do this thing I don't like]?" is not a valid question.
HN is a vast community of many different people who think and behave differently.
Sometimes a few more people will downvote your comment than will upvote it, either because they disagree with your point or they dislike the way you expressed it.
But when you complain about downvotes, you lose multiple times over: you fail to contemplate and reflect on how your answer could have been better, you come across like a bad sport, and you break the site guidelines [1].
In this case, it seems like people just disagree with your claim and have explained why in replies.
No big deal, all you need to do is reply politely to demonstrate the correctness of your point.
In the last few months it has become a monoculture similar to Slashdot. The general view has become if you don't agree you must not know what you are talking about (this is seen upthread).
Stories like these allow people to dislike Intel, say it is run by dumb managers, and just generally complain.
Comments lamenting how much better HN "used to" be have been a constant from not long after it began:
https://hn.algolia.com/?query=%22hn%20used%20to%22&sort=byPo...
Please, if you want HN to be good, be the change you wish to see!