Schneier on Security

Clive Robinson • July 14, 2022 5:51 PM

@ lurker, Winter, ALL,

Always log out immediately you’ve done your business.

It may not help you…

As I was saying quit some number of years ago, you need to understand the consequences of,

“Security -v- Efficiency”

As an almost invarient rule, Efficiency trumps Security as “speckmanship sells, security smells” in most marketing peoples heads.

So you need to remember,

1, It’s a shared resource problem.
2, Shared resources are almost never cleared / nulled out.
3, Cache algorithms work in some odd ways.

Because getting data from semi-mutable memory like a mechanical hard drive into Core RAM is torturously slow Pages of memory get left in Core RAM untill either “paged out” or “overwritten”

Likewise Core RAM gets alocated to processes in various ways sbrk(), malloc() being common. They do not generally null the page of memory.

Data in Core RAM has not been read into CPU registers for quite some time, it usually goes through two or more levels of cache, and is “premptive” in many ways including data from other processes.

I won’t bother going into the way the algorithms work, but it is possible to find “old” data that has not been nulled out or overwritten in the chain from harddrive to CPU register…

Thus the question is,

“Can a new process get at this old process data?”

The answer to that is obviously yes if there is a mechanism by which it can happen.

As I’ve mentioned before you can use malloc() and free() to make a data path that is not realy visable in the source code,

1, Use malloc() to create a buffer,
2, Write data into the buffer,
3, Use free() to release the buffer.
4, Use malloc() to create a new buffer the same size as the buffer just released with free().
5, Examine the contents of the new buffer…

With a little care about how you use malloc and friends, you will find you can say, call a sub to read a secret key in from the user into a buffer, and pass this buffer to the crypto algorithm key handler. On return from the handler release the buffer go on and do a whole load of stuff provided it does not use malloc and friends. Then call a sub that creates the new buffer and passes it onto another sub that now has access to the secret key…

You can hide this by “overloading” the error checking sub, that is when called it “checks the buffer” to see if it exists, and drops into checking the contents are valid, if so it does not clear it instead it just marks it as valid and returns as OK…

You would be surprised at just how easy it is to hide such things from even quite experienced software developers.

There are all sorts of other tricks that happen because “Efficiency trumps security”…

Clive Robinson • July 26, 2022 1:38 AM

Opps,

My above was to @Denton Scratch.

Clive Robinson • July 26, 2022 5:48 PM

@ JonKnowsNothing, Denton Scratch, ALL,

“If you spend 10yrs, after 5yrs college or school, honing your skills in Computer Language XYZ, can you effectively re-train for another 5yrs plus an additional 10 yrs for for Computer Language MNO?”

This is almost certainly going to turn into one of those long threads, as has happened in the past.

The root of the problem is the education system.

These days you get taught,

“What emoloyers want now.”

Not what,

“Engineers need for a sustainable career.”

There was a time some fourty to fifty years ago when you were taught as standard the very foundations of not just the way computers worked but fundemental logic, set theory and the algorithms based in them as well as abstract data types.

This was all done in a “language independent” way. Thus it did not matter what CPU you used, if it was 8, 12, 16, 24, 32 or 36 bits wide, or if it had a small or large register file or even Cray type register systems.

These days it’s not about such fundementals you can easily rebuild on, but expensive environments and tools and code re-use to the point where it’s not even coding but plumbing.

But there is also the,

“Man and his dog”

Problem… Where the man is effectively a “hobbyist” and his dog is some pet “programing language” or “library” etc.

Because corporation managment due to neo-con mantra are always chasing down the minimize cost spiral to hell we occasionaly get reminded Log4J being just one example I hope most can atleast remember…

Which brings me to the next appaling thing in the majority of the software industry, we do not record our history let alone study it, thus we do not learn from mistakes and re-live them over and over…

There are known ways to fix these problems and I’ve mentioned them before then been shot at by people who keep avoiding the actuall issues. Thus blaim the messenger rather than take a little time studying the history of the industry and learning the lessons.

As an example we all know what evebtually happens when you build up a Tsunami of Technical Debt. Most readers here know what the basic thing that needs doing is…

But that is not fun, or sexy, or leading edge, it’s dull and requires thoughtful and commited behaviour over an increased period of time…

Writing code that can be effectively maintained requires a certain skill set, that is not difficult to aquire. But many “ace coders” hate developing software this way…

As for “full stack” do not make me laugh / cry, any CV or Job advert I see with that in it tells me something…

Any way if I mention “Victorian” boiler makers, you should be able to search for some of my previous comments…