Are state actors or others trying to take advantage of meltdown needing fixes & patches to insert their own version of fixes & patches that end up benefiting them?
As far as we know, there has never been a single attack using either of specter or meltdown issues. No code had been found, nothing.
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.
Meltdown is almost trivial to take advantage of, as these things go, and it was discovered independently by more than one researcher. That makes it somewhat more likely to have been exploited by a government level attacker.
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.
Trivial, yet nobody has managed to produce a working exploit that doesn't require a running start. The poc exploits wouldn't work in the wild. They are running with interference of a real system.
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.
Absolutely. I will be really pissed of if I'm forced to run a -30% kernel performance on my dev laptop, or god knows how much of my 1/2 decade old T420's to fix a problem I don't have. Yes, I expect my cloud provider and bank to apply the patch, my ARM based router is fine.
- 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.
I'm afraid that jnordwick doesn't consider PoCs to be "real" enough for some reason. [0] I think he's waiting for a piece of malware to be found in the wild before he'll consider it a problem.
Just something that would work in the wild. There are a number of things that might theoretically be possible if the machine of complicit with you but aren't actually exploitable.
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.
I'm not sure I understand his position on Spectre, but he's been pretty clear that for the most part he's been talking about Meltdown. Honestly I'm not familiar with how much of a perf hit the Meltdown patch alone causes, because I always see the bad perf numbers with their combination, but I suspect it's bad. Since Meltdown has no JS exploit, there's no reason to worry about JS. Given that browser exploits are out of the question, the threat reduces to the normal threat of running untrusted code. I see no reason to worry more about Meltdown specifically than I have to worry about any application I run sneakily running `xinput test-xi2 --root`, so given the choice, I'm not going to apply the Meltdown patches on my desktop machine and suffer a perf hit for no good reason. Spectre patches, maybe, but I might not if the browser situation is confidently dealt with.
I think it would be useful to write up a technical article on the cache side channel attack and how it is used by meltdown and specte and their different methods of exploit.
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).
Why does HN not allow people to question things like this? Any attempt to bring some non hyperbolic view to the topic is continually voted into the ground.
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.
I know what you mean, and I've felt your frustration before.
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.
It is a relatively recent issue. HN was a lot of our escape for Slashdot. But HN has developed the same bandwagony, anticorporate, managers suck, other people are stupid angst.
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.
You're still making the mistake of extrapolating the entire community's nature from a small sample of comments and votes. It's a common reaction when we feel like our own opinions are being attacked or undervalued but it means we fail to appreciate and value the side that is worthy of our support and appreciation, and we fail to take responsibility for the role we all have in making the site better.
Comments lamenting how much better HN "used to" be have been a constant from not long after it began:
