Schneier on Security

Clive Robinson • December 16, 2021 11:59 AM

@ Bruce, ALL,

And a second vulnerability was found, in the patch for the first vulnerability.

Who’s up for a game of dominoes to celebrate the longest nights?

Rumour has it the heat is rising in the server room, as people have a rush on for mints, as not every one wants chocolate coins for Xmas…

Clive Robinson • December 16, 2021 4:15 PM

@ William Entriken, ALL,

I have also reported another vulnerability

And so the dominoes keep toppling…

Anyone “making book” on if it will still be toppling after the US Gov deadline of Christmas Eve latest?

Or are people going to have to climb out of the trenches singing “Silent Night” or playing the bag pipes[1].

[1] The famed story of the unoficial Christmas night ceasefire in WWI. Apparantly it started with a Minister of a Scottish regiment playing a tune on the pipes about home[2].

[2] This should not be possible on bagpipes, but… As it’s that season may this raise a smile,

https://m.youtube.com/watch?v=1iSDshYN2WY

Clive Robinson • December 18, 2021 7:39 AM

@ ALL,

And still the dominoes keep falling…

People are starting to talk about,

“Mega Corp stealing code from Free Open Source”

But that’s kind of hiding the point, because the,

“Thousand eyes”

Issue will be brought up next and then the arguments will just turn into flame-wars and the real problems will not get solved…

I know some people will want to shoot me down for what I’m going to say, as they have tried to do it before and well failed in their over emotive arguments…

As I’ve said before “software engineering” as a meaningfull expression is a joke because the reality is outside of a few niche markets,

“There is no engineering in commercial Software application development.”

It’s not even “artisanal” in most cases either. The reality is it’s “Bodge it DIY”, not even upto “DIY 101” standards, or it’s “No time allowed in the deadlines”…

Most developers within a relatively short time get past “DIY 101” level in their own code otherwise they would not be being paid. So “No time allowed…”.

Which is one major reason most developers do not use their own code… Nor for that matter read and understand the code they do use. They simoly “plumb it in”. We know this, it’s why the XKCD “Dependency” cartoon exists.

That is developers either download a library or they “cut-n-past” from some online repository of “example code” of which there are many, and nearly all are terminally deficient.

Why are they terminally deficient?

Because if you look at “example code” the thing that is missing is “error and exception handeling”.

That is the assumption all input has been validated on the left (input) and there will be no issues to come back from the right (output). So just show barest functional code to demonstrate usage…

But this problem goes deeper, it’s built into the majority of multi-tasking commercial OS’s. For them to work the basic assumption is every thing flows from left to right, and if anything happens at the “output” the OS “blocks the execution thread” and goes off and does other things untill the issue at the output has cleared, or it times out and kills the thread…

It comes as a realy big shock to many developers when they have “first contact” with RTOS work. Most get Banjanxed and can not get into the required thinking process for quite some time. Some never can, and it’s an issue that is only going to get worse with the very necessary rise of “Parallel Processing”.

In Commercial OS’s you sometimes “HAVE TO” write bi-directional code, the classic example being a “Terminal Emulator” or similar communications code. Few get even close on their first attempt and for years POSIX just pretended the problem did not realy exist…

The solution is tucked away deep in the OS, the “Oh so, way to slow” way is via “Signals”. Back when PC’s ran single user the solution was a “polling loop” the user code just sat their spinning, occupining all the CPU, fast but realy inefficient.

The correct solution is “easy to say not so easy to do” it’s “Use hardware interupts and fast IO drivers to a cascade of ever larger buffers”.

In essence you split the problem into layers, at the bottom is fast very short IO drivers that copy to/from short circular buffers on hardware interupts. These circular buffersset flags that in turn are dealt with by time based “round robin” IO handlers that copy to/from the short circular buffers to much longer kernel IO buffers, that on a priority then round robin basis get pushed into user buffers and it’s here that signals and blocking usually are handled… But two things of consequence happen,

1, This process is slow but mostly does not matter as by far the majority of code used not to be bidirectional, just “gated”.

2, The bidirectional streams are now segregated and thus can in most minds be both considerd left to right.

The first is why we are hearing more about “user land IO for through put”…

The second is why just about everything gets fitted in the from “left to right” model. And this model is the underlying cause of this issue…

As I’ve previously noted it causes developers to push error trapping as far to the left as they can, and business logic as far to the right as they can…

But “What of exceptions?”… Well many say to themselves “they are so rare they never realy happen” well they do, and that is when the OS raises a signal… As most commercial application developers either don’t or can’t go there… Then you get the OS hitting what were once just called sig_abort or sig_abend[1] and turning it’s toes up. Back in the older MS-DOS/Windows days that gave the “Blue Screen of Death” if you were lucky otherwise it hung up or occasionaly went nuts or turned “Old Smokie” on you[2].

So there is an almost endemic mind set in both commercial and OSS application developers that all “errors will be stopped at the left” and “no exceptions will come from the right”.

Yes it saves a lot of code, thus time, but then things do go wrong…

Which is why right now people are going “Whaily whaily me” over log4j.

But what of next week? Next month? Next year?

Well there is a whole almost endless procession of “truck loads” of such problems comming down the road.

All entirely predictable, all entirely preventable, and none should happen, but they will… Because,

1, Developers don’t engineer the code…
2, Because managment don’t want them to…

For the first to change, managment has to let it happen, only they won’t. Because “First to Market” is the Commercial Software Industry mantra… Which gives us the ICTsec Industry as a rather unplesant symptom, not the cure.

[1] Back in the early “big iron” days signals were wild and deadly in most cases or could inflict wounds in storage etc that were mortal. IBM came up with sig_abort and sig_sabend and sig_uabend. But these were considered insufficient as resources improved. These days we have the likes of POSIX signals in their many varieties and it can take a while to get your head around them,

https://en.m.wikipedia.org/wiki/Unix_signal#POSIX_signals

My advice, take your time and importantly draw diagrams to help your thought processes.

[2] Some earlier computers could actually blow up see what was one called “poke to die”[3] and similar with 8bit home computers in the early 1980’s. One example was a casset motor controller that was driven by a “bridge driver” that alowed it to be forward and reversed. To save money / hardware / PCB space there was no hardware lockout prevention, so it was possible to turn on the bridge transistors and put a short on the power supply…

[3] Back in 8 bit home computing you had two high level programing languages, BASIC and very rarely Forth. Everything else was done in assembler… To assist in doing assembler, BASIC had two instructions PEEK that read a byte from a memory address, and POKE that wrote a byte to a memory address. Back then most IO was “memory mapped” within the 64k byte range of a 16bit address. So if you had dangerous hardware and some kiddy wrote a loop that “Poked Memory” address after address like a game of Russian Roulette sometimes they would get lucky sometimes they would not.