Schneier on Security

Clive Robinson • August 22, 2022 8:16 AM

@ Bruce, ALL,

“This is a dumb crypto mistake I had not previously encountered”

Yes it is, but…

It’s also “expected” in a way.

If you are developing a cryptographic application you’ld want to run “the standard tests”. So at some point the standard keys would get used.

Now the real questions to ask are,

1, How did the test key get left behind?
2, Was it by accident or design?

That is,

1, Is it a very stupid mistake.
2, Is it made to look like a stupid mistake.

As gets pointed out from time to time “Plausable deniability” is very useful.

But this is so stupid, it’s almost too stupid.

I can see one way for it to happen and that is the “two team handover” issue.

Generally when one team hands code over to another team, these days they also hand over a bunch of “tests” for the second team to run and check they have not broken anything later.

The “Agile Alliance” and similar strongly push “Test Driven Development”(TDD) which very loosly is,

1, Read the spec
2, Write a bunch of tests[1]
3, Write the code to pass the tests
4, If a test fails fix code
5, Refactor the code
6, Keep testing and refactor looping

Yes it produces code that passes the tests but…

1, Are the tests correct?

And perhaps worse,

2, Do the tests in effect become built into the code?

The answer to the last point is often “yes” which is where the danger arises.

But even if it’s not direct artifacts of the tests getting left in the code, the code structure and more are clearly a product of the TDD methodology in use.

As for are the tests right? Well often most do not even know what they should be testing for or how, just that a new test should fail and the code changed to pass[1]…

Thus the tests are perscriptive and other testing techniques which in experienced hands are way more effective get ignored.

To say,

“Test artifacts get left behind in TDD”

Is shall we say an understatment with some developers…

So yes I can see “Stupid being to Stupid” but that’s to be expected with “features over functionality” driven managment with commensurately short development cycles.

There are also other ways such things can get “baked in” as develipment moves down a chain.

[1] One mantra of TDD is “new tests must fail” it’s based on a false argument that a test is not functioning if the existing code passes it… Therefore by definition you are not writing a test to the specification, but to make the existing code fail in some way. This is dangerous because when you “refactor” you can cause other tests or code to inherit something undesirable from the new test, that may actually introduce a fault.

Clive Robinson • August 23, 2022 9:46 AM

@ Erdem Memisyazici,

Re : Independent Certification.

“Rarely do you see any software flaws in gambling machines “

No, nor do you see it in “intrinsic Safety” electronics, or “medical equipment”, and most other electronics that has to go through rigorous “Independent Certification”.

Even aircraft systems when “Independently Certified” don’t have critical software flaws. Shame that Boeing software was not “Independently Certified”…

Oh and you don’t see it in the airside of phones which is likewise rigorously tested in “Independent Certification”, but you do on the user side of Smart Phones and the like that does not get rigorously tested, and certainly not “Independebt Certification”.

Which is the point I was gently making to you earlier with,

“Because the electronics in gaming machines, replaces mechanics, on which several legall constraints are placed on them, including payout rate etc, and these machines are tested before they are approved for use.”

In fact they have to be “certified” in most places which requires them being “Independently Certified”.

As I’ve indicated in the past I’ve worked in electronics and software design in all these areas befor, and I have been a major inovator in them by bringing new technology and features which previously were not attempted because others thought the “Independent Certification” was to rigorous to alow them. The only reason I could do so was two fold,

1, I know how to not just read the certification requirments, but how they are tested[1].

2, I know in depth how to design intrinsically safe, fail safe electronics and intrinsically safe, fail safe software.

As a result I’ve had no qualms about puting my name and professional reputation on the products I’ve designed in these areas.

Designing safe and secure software requires,

1, The correct knowledge.
2, The correct state of mind.

As I’ve said before the design of secure systems “Is a Quality Issue”, likewise so is the design of safe systems.

As we all should know one of the first things required of a process for such “Quality Issues” is,

“Total buy in from all involved”

If that is not there from before the project starts, from the most junior to the most senior involved then your chances of success diminish correspondingly.

[1] I’ve also done testing to a very high level and been involved with designing new testing techniques to minimise testing cost and improve testing accuracy.

Clive Robinson • August 23, 2022 3:30 PM

@ L.S.

Re : Reason X

“The direct result is mistakes like this.”

In the past I’ve been lucky, in that managment listened to me, all be it grudgingly, because I not only got results, but also very importantly Awards for their companies.

One of the reasons I moved out of engineering design, was because “marketing” and “human resources” were making too many gains in the “power grab” game, and it was to me becomming clear which direction things were moving.

Sad to say all but one of the companies I worked for nolonger exists… The fact I saw it comming last century along with the dangers of out-sourcing etc but could not stop it… I guess is my cross to carry, but even back then it had an inevitability about it, which is why I got out.

I see the same inevitability in the ICTsec industry, and it does not bode well. I guess it’s time to see which direction to jump in next.

Oddly it may be back in the direction of engineering design, because the events of the past couple of years may have made their managment more receptive in places.

Clive Robinson • August 23, 2022 9:34 PM

@ lurker,

Re : A step to the left and a jump to the right[1].

… problems with “moving input validation to the left”.

It’s a form of lazyness some incorrectly made into a virtue now it’s a very pathogenic disease that is almost genetic in behaviour.

The argument once was and sometimes still is,

“It gives clarity”

But that was at best a fig leaf, which goes back at least as far as the 1970’s to my certain knowledge if not I suspect further to the 1950’s.

The reality was to try to get some kind of “efficiency” with highly limited eye wateringly expensive resources.

This was known to be a bad idea when C was developed and certainly discussed back in the earliest days of Algol.

The argument was over the location of,

1, low level logic.
2, supporting logic.
3, business logic.

in a high level language program.

Which whikst it might sound esoteric had very real performance issues back then as it still does today. Even though few realise just how CPU and below architecture dependent it actually is (think executable code caching for instance).

Back then resources were not just speed limited but memory limited and Virtual Memory was a very new idea and not realy available except in the most expensive of mini-computer systems and only some high end “Big Iron” mainframes costing the equivalent of a hundred years or more of professional level salaries.

However primative code block swapping –without hardware address translation– was in use. And actually quickly gained use in early Personal Computing in the Apple ][ in the late 1970’s and in IBM PC clones in the mid to late 1980’s. It was usually done by “overlay” where code at a high memory address would get loaded at an appropriate time then as the program progressed this would get overwritten by a new set of code appropriate to the part of code executing. Those that programed the likes of the 8086 realised that was why there was four segments for addressing (as a “poorman’s MMU”).

Obviously you could not overlay “low level logic” code, because that would be IO and similar BIOS/OS code needed throughout a programs execution. Nor could you realy overlay the high end “business logic” code as that would need to contain the appropriate overlay logic to pull in the overlay blocks of code. Which left the “support logic” code.

To understand this better you need to look at code from a higher level. Imagine you are writing every piece of code without macros or much in the way of functions. What you have is three parts,

1, Set up,
2, Business logic
3, Tear down / clean up.

The first and last are “administrative functions and belong to the OS, so often do not get addressed in high level languages.

The second is what most of us would consider the “program” these days. If you were to draw it out as a diagram you would end up with a control loop at the top, that calls or loads various functional blocks at the next layer and so on down through horizontal layers to the actual hardware control. It forms a pyramid of code where each lower horizontal layer is larger than those above.

However the lowest layers contain almost the same code over and over, which although fast in terms of CPU cycles is very inefficient usage of memory which was even in the 1970’s tens if not hundreds of dollars a word. Thus speed at the lower horizontal layers took a back seat to minimizing memory usage. Thus the hardware code got pulled into a single generalised code block and so on back up the layers of the pyramid, making it look more like a diamond.

It was in that “fat middle” layers where all the support logic was. So the same rationalisation was tried but… These middle horizontal layers had sub-function in them which were distinct. Which made it easy to partician up several horizontal layers vertically. Thus easy to convert into overlay code that only needed to be loaded into “CORE Memory” when that sub-function was used.

So to aid in this process the idea of seperating out the high level “business logic” and putting the “support logic” into an “overlay library” where it would be grouped in memory came about.

To do this the core business logic had to be seperated from the support logic… And this is where a fatal mistake that still haunts software development happened.

Ask yourself what “support logic” is and it boils down to “errors and exceptions”. Some of the error checking is “range checking” if you actually strip out the ranges you end up with code that can be generalised or as it gets called these days “refactored” for “reuse” which is seen as some kind of “Holly Grail Mantra” that sells all sorts of nonsense to management as “labour saving”, “resource optomisation”, “Productivity improvment” etc. Or to be blunt appearing to save costs by employing less skilled labour[2]…

But this nonsense also got sold into education… Explaining code or writing “example code” becomes oh so much easier if you strip out all that support logic. Few actually bother to find out what the ratio is between support logic and business logic is. Depending on how you define low level logic roughly 20% or less of the code is business logic… The “code reuse” can reduce that to 15% but the required generalisation code in the refactoring process to do it takes it back up again (so the actual saving in resources is often not there, in fact the opposite).

Thus shifting “error and exception” handeling appears to make things less messy when you design the code. As you can just concebtrate on higher level business logic.

Shifting “errors” to the left and shunting “exceptions” to the “Blue Screen of Death” code makes the business logic design even simpler thus from both managment and educators perspectives is a gift from heaven (and a disaster for the rest of us).

One danger is it falsely particians code which for those that remember going from the original client-server model through “middleware” to the mess we are in today… Where “validateng user behaviour” is done in JavaScript on the client (see hit Ctrl-F/F12 to see SSN security vulnarability as a recent famous example). Should tell you that this “move to the left” is a realy bad idea.

Earlier today I was talking about the perils of TDD and Shannon Communications Channels[3] it’s exactly the same problem in a different disguise. Partitioning means implicit “communications” and “communications” can go from “in thread” to “inter system” later which the original designers never envisioned or intended. The result is you open a vulnerability via the communications channel behind your user input checking, thus have a massive security hole appear, just waiting to be found and exploited.

The sad thing is the developers of C were well aware of this issue, it’s why they emphasized the use of both functions and macros. Thus “errors and exceptions” and all sorts of validation could be put directly in the actual business logic where it realy belongs.

Which brings us to your question,

But who is responsible for putting in either a block to stop leftward movement, or a validator over there?

The actual answer is “every one” as it is fundementally a “Quality Issue”.

The reality is though, it has to be senior managment getting to grips with the drivers of these behaviours and purging or ameliorating them. But to be ready to do this they need to stop listening to neo-con mantras pushed by very short term thinking shareholders and the like (which as that effects senior managment benifits etc is not going to happen in the current corporate world).

But also as designers and developers we have gone way way to far down both the “code reuse” and “code refactor” paths.

These days software is not so much “developed” as “plumbed together” it’s not healthy for the ICTindustry or the Designer/Developers.

I actually cringe when I see C++ and now C Standard Libraries. As for Java, JavaScript and Python does anyone know of something for which there is a use but there is not a library?

But have people actually looked at not just the quality of these libraries, but just how inefficient they are?

The problem with “generalisation” especially for “code reuse” is it is always horrendously inefficient in both memory and CPU cycles. Worse nearly everyone who uses the libraries will never ever learn how to do the things they require with out them. Thus all sorts of design errors come “built in” because in the main nobody knows better, and even if they do, they are not alowed to use that knowledge.

[1] See Rocky Horror Show if you don’t get the refrence 😉

[2] You could write several books on the very short sighted and false economy of this notion. In fact several people have but the neo-con mantra of “Don’t leave money on the floor” wins almost every time and costs mega bucks down the road, only a fraction of which is covered by the term “technical debt”.

[3] see my comments above, but speciffically,

https://www.schneier.com/blog/archives/2022/08/hyundai-uses-example-keys-for-encryption-system.html/#comment-409184

And my first comment on this thread about the perils of methodologies taken too far, for which I used TDD (it’s not the only one, in fact the same issue appears with nearly all methodologies that get overly formalised or perscriptive by those on the make and their fanbois).