zlacker

>>chei0a+(OP)
So I read the blog post and skimmed the PDF and I'm left with some questions. IF these security issues have been present for 10 years, but there hasn't been any widespread malicious action on them, are they really issues?

To create an analogy, my car doesn't have bullet proof glass, someone could easily shoot it up and i'd be dead. But nobody really goes around shooting up cars, so is it an issue?

>>jbob20+I2
Of course they are. We ran the Internet on C code that was positively riddled with trivially exploitable stack overflows for 7 years after the Morris Worm demonstrated RCE through overflows --- 6 years after the "microscope and tweezers" paper explained how the attack worked.

Exact same story with error oracle attacks in cryptography.

Attackers go after the low hanging fruit first, and then they move up the tree.

>>tptace+e5
Well that was kind of my point, that hardware is so far up the security tree, it's almost moot (that's kind of my question I guess. Is it far enough up that tree to be moot?). To compare with my analogy, a hitman doesn't need to shoot me up while I'm driving my car, he can wait until I've exited the vehicle and negated any protection I might have had. Similarly, a hacker can avoid the hardware entirely and wait by a printer to read those secure financial documents. Or they can watch over your shoulder while you type your password. Etc. Etc.

>>jbob20+C8
It's the 'Holy Grail' of exploitation though - if you can back-door the hardware as she's suggested in the paper, nothing in the software stack can detect it, which means you cannot know if your machine is secure or not.

The fact it's very hard to achieve means it's not something that's likely, but if a government decides that it wants to commandeer your computing hardware, there's nothing you could do to stop them, plus you'd never know that it occurred.