Schneier on Security

Clive Robinson • April 17, 2020 8:34 AM

@ BAE,

So where was the weak point? In the supply chain. Some little company, in some backwater downunder. Didn’t this happen before? Yeah that’s right, back in the’80s.

Supply chain : check
Small company : check
In nowheresvil : check
Happen befor : check…check
Back in the : 80’s 90’s 00’s 10’s 20’s…

The answer to why is,

We did not learn the first time or the thousands afterwards…

The reason is,

We ignore our history, we don’t write it down, we don’t teach it, we are thus condemned to reliving it over and over.

The dull reason is rather than accept the tools we use are imperfect as most engineers do. Thus learn to live within the capabilities of what we have we keep throwing more on top hoping to abstract that which is imperfect into a flight of fancy which like all dreams are perfect, including those “perfect nightmares” which are all we can remember into the future and just keep trying to run away from…

We now have CPU’s with such complex ISA’s that it’s beyond most peoples abilities, even those who designed them only know one small part… We then have this huge gulf on the other side of which is a language so bereft of usefullness that it has less power than the ISA’s of early 8 bit CPU’s used in home computers and games machines of the late 1970’s.

This language that even it’s designers admit is at best not well designed forms the foundation of nearly other language since, be it first hand or multihand. Beneath nearly all lurks C…

The only advantage of C is that you can learn the base language bad as it is once, in a day or two then spend much more time learning how to deal with memory handeling abstractions for atleast as long as it takes to learn the standard libraries…

But somebody decided this abstraction was not sufficient so they dropped Objects on top and like a triangular object it did not fit well into a round let alone spherical hole…

Hands up anybody that knows all the C++ libraries sufficiently well to use them in their entirety without using the documentation?

Be honest now…

The hidden problem with C++ is C and C’s hidden problem is memory, and nearly all security faults not using a human as a stepping stone are effectively memory access faults.

So what did those software people do? They came up with “complications” from stack canaries through to Address Space Randomization mostly written in C or above. And guess what, they don’t realy fix anything as first RowHammer then Spector and Meltdown showed. However those “memory” issues were known back in the 1950’s and they knew back then that if you could get in what we now call the “computing stack” below the level you develop and implement your memory security then you have no security…

That is all the security at the memory layer and above uses the notion that “The memory won’t change”, as the fundemental foundation stone on which all the security is adsolutly dependent.

Just changing a single bit in one word in “core memory” can break all of the system security…

And all those supposadly clever features like Intel’s SGX and other “secure enclaves” all fail if you can get below the memory level in the computing stack directly or indirectly. As predicted all those “go faster” additions in overly complex CPU’s open up “side channels” as the price of squeezing that extra “Specmanship”… As researchers are showing it truly is “The Xmas gift that keeps going”, first with the hardware, then with the work arounds for the hardware faults.

I hope people are finally getting the message that,

What we have can not be fixed!

At best we can mitigate, and oddly the closer to the failing the mitigation is, the more likelyvit is to fail to another attack… Mostly because the mitigation tries and fails at the “Security-v-Efficiency” issue. As a rough rule of thumb the more efficient something is made the less security it has, generally becausevit opens up the bandwidth of side channels making it effectively transparent to attacks. Yes there are ways you can design systems to be efficient and then close down the side channels, but generally only the side channels you can predict.

As I point out from time to time what many think as a “one way process” very frequently is not. Because we add capabilities for “Errors and exceptions” and they propergate in the opposite direction to the data flow, right back through our mitigations such as firewalls and data diodes all the way back up into user processes…

These things have been known again from WWII and arguably back more than a century and a half to the Victorian era and the likes of the telegraph and telegraph relays…

But we don’t teach such history to students because apparently “they don’t need to know”!!! I guess I could liken it to not teaching about “metal fatigue” and other “work hardening” issues to those designing all the infrastructure, vehicles, buildings and just about everything else the failure of which would most likely cause a “loss of life”. Or not teaching chemists and others about the problems with “acids and bases”…

One of the things that seperate real engineering from other endevors is learning about why things fail and taking it on board and accepting responsability for them. This is what happened all be it reluctantly with “boiler making” where artisanal crafting gave way to science based design. Thus engineers take responsability for designing systems and their components so they either can/will not fail, or will fail in a safe way…

Anyone know of a Computer Science or Computer Engineering course that realy teaches the history of computer failures, the hard lessons learned in detail and how to design them out of future systems?