It must be up there amongst the greats, probably with the "halt and catch fire" op code. Normally they just patch this stuff with microcode and never really tell anybody, this time that won't work.
I'm not entirely convinced it was a mistake at all (dons tin foil hat), Intel have been making suspicious design decisions to their chips for a well now (think this, Intel Me, hidden instructions, etc). It seems clear to me that this security by obscurity approach is quite frankly crap.
>And now I can't update my OS before making an installation USB because Canonical can't just follow Linus' releases. Thanks.
Linus' releases need some sort of buffering before they can be considered stable, often distributions will apply their own patches on top. Also consider the scenario where Linus releases a bad kernel and no testing has been performed before rolling out to all Linux users.
Keep in mind that whatever "evil agencies" would have asked for this would most likely find themselves vulnerable, and nobody would sign off on.
I do agree, however, the "security by obscurity approach is quite frankly crap". The fact that even large corporations (not the big 5) can't even get away from ME speaks volumes about why this is a bad idea. Facebook isn't the only company with important data.
Amen. It blows my mind that some people think clever techniques like speculative or out-of-order execution must've somehow how nefarious intentions behind them. Come on HN...
And in the case of SMTP, it's basically a pinata of bugs for the last 30 years regardless of platform
Alone the risk would not be worth to intel. Do you really think, nsa has enough money to compensate for this backslash and newscoverage?
Any nonuniform distribution in any quantity that is not part of the spec is exploitable!
Oh, you don't want to do that?
It just keeps popping up, someone finally thought to weaponize it.
Someone published its weaponization, you mean :)
But yet and still we found out. So yes, this security through obscurity approach is terrible (with a code embargo being the obvious exception).
They only update microcode when they have to. When doing otherwise risks... Well, this kind of mess.
You dont wanna know how many times I've rebuilt my gentoo system chasing after retpoline kernel & gcc builds that just... Break everything.
It should be interesting to see how it all develops
See https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAn...
Tbh it’s not the most meaningful of statements, but it’s food for thought.
Or, to put it another way, I have no clue to what you're referring--what do references have to do with "The Billion Dollar Mistake"[0]?
[0]: https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retra...
EDIT: my apologies, that joke was actually pretty good.
However, I completely missed the pun. Cheers :)
> On system reset, the vector table is fixed at address 0x00000000.
Also, I'm not an expert on the C standard, but in my understanding, it doesn't "break" it. That is:
* Address 0 and the null pointer are distinct
* A 0 literal treated as a pointer is guaranteed to be the null pointer
* The null pointer is not guaranteed to be represented by all zero bits
* If you get a pointer to address zero via pointer math or by other means than a 0 literal, you can still access address zero.
So the question of what happens when you actually do that is purely up to your compiler and architecture. In most cases, if you manage to get the NULL pointer value through pointer arithmetic, it will still compare equal to the 'actual' NULL pointer and treated as if it was a literal 0, so that doesn't allow you to get around NULL pointer checks. The only situation where it really matters if the NULL is only known at runtime, since that may have implications on optimizations. Since dereferencing the NULL pointer being undefined behavior, the compiler can remove such dereferences, but it can't remove the dereference completely if it can't prove the pointer is always NULL. There is nothing preventing the compiler from adding extra NULL checks in that aren't in your code however, which would foil the plan of generating a NULL pointer at runtime to dereference it. So unless your compiler explicitly allows otherwise, you cannot reliably access the memory located at the value of the NULL pointer - as far as the standard is concerned, there is no such thing.
Talking specifically about the ARM vector table, that largely works ok because only the CPU ever has to actually read that structure, normally you C code won't have to touch it (If you even define it in your C code. The example ARM programs define the vector table in assembly instead). If you did ever have a reason to read the first entry of that table from C though, you could potentially run into issues (Though I would consider it unlikely, since the location of the vector table isn't decided until link-time, at which point your code is already compiled).
On that note, it's worth adding that POSIX requires NULL to be represented by all zero bits, which is useful. Lots/most programs actually rely on this behavior, since it is pretty ubiquitous to use `memset` to clear structures, and that only writes zero bits.
(Sorry for the long comment, I've just always found this particular part of the standard to be very interesting)
I am not sure your point. The reason modern systems don't map memory to 0x0 is because NULL pointers exist. It is a reflection of a leaky abstraction equating pointers to references. That leaky abstraction has (or so the argument goes) caused >$1B in software bugs.
The other mindset would be "malloc always has to allocate memory or otherwise indicate failure; you cannot cast from a integer to a pointer; you cannot perform arithmetic on a pointer to get a new one; you must demonstrate there are no hanging references when freeing". This is essentially what rust did for safe code.
The reason why I indicate so much skepticism is that rust is the first time I've seen the problem solved well in the same problem space as C. Ada has problems of its own. It's more about how small assumptions can have massive economic (and health, and safety, and ethical) consequences. Certainly comparable to a speculative execution bug leaking memory in an unprotected fashion--in both cases the bugs find their way through human error in evaluating enormously complex systems for incorrect assumptions :)
Llvm won't use it for anything. (I think it starts putting things at 8). Trying to access it explicitly in C will generate `unreachable` instructions.
https://www.lucidchart.com/techblog/2015/08/31/the-worst-mis...
"biggest" by net financial loss to a single entity? I dunno. How much did that failed NSA launch cost the state again?
I didn't hear about that one
I suppose if there was an exploit targeted at a specific program, it would be possible to work out what location the secrets are stored in?
Additionally some hardening methods like stack protector make stack allocated objects stand out a lot from register values.
Given that whoever writes is would also have access to the other program, they would have a lot more information on where to look in memory.
(Obviously if you have nation states or serious criminal organizations trying to breach you regularly, this is more serious)
Heartbleed was touted as being bad by those that didn't read too far into it. You could scrape memory, sure. But it was always random fragments. This lets you make targeted address attacks. Force a process to use that memory space through a NOOP and now you can start scraping at will. Or you can just do an entire memory dump and pull things out in plaintext (like scraping Firefox passwords, which we've seen done already).
The only reason this isn't worse is it requires the ability to execute code on the machine. It has high (near absolute) impact, but low-to-moderate on the ease of execution.
This title is held by autorun.inf which has caused over 20 years of broken, vulnerable behavior and, AFAIK, is still going strong.
It wasn't that bad, because people took it seriously. But there were still tons of practical systems affected and billions of corporate dollars associated with fixing it.
So when you say "biggest mess up" you gotta define specific qualifiers. Because Meltdown/Specter is going to be solved by simply... buying a new CPU. (And retrofitting the old ones). So it consist of mostly a patch.
A BIG important patch, granted. But it's still just a patch. But some ATM's aren't going to start spewing money like they did on Y2K.