Schneier on Security

Clive Robinson • October 28, 2022 8:19 PM

@ ALL,

Re : There are no details yet.

So one “YOU HAVE TO ACT ON” if you run SSL 3.x… Because the last SSL critical warnings were nasty nasty nasty, so you don’t want to be on the list of entities “Shish kebabed” by this one.

But to little is currently “public” to say what is or is not vulnerable or why, thus how to mitigate it.

My advice based on what I know from past experience is “mittigation in advance” rarely is actually counter productive, if done judiciously.

But like most you probably do not have sufficient technical information available to you to do any mittigation with a surgical precision. Thus any systems with SSL 3.x on them, even if you do not think it’s in use need to be put on a list to be mitigated.

But that just brings up the “How to mitigate?” question to which there are only realy two answers currently,

1, Not being communications connected.
2, Watched critically 24×7 for any kind of unusual activity.

My reasoning would be the first for a few days might be the only option for most systems. With the second reserved only for systems that have to be connected.

Oh and remember, by “connected” I do not just mean “the Internet” because if this vulneravility is in use, then it can also be used on any and all networks where an attacker internal or externally could have reached…

So fingers crossed folks, and lets hope the law of,

“Target Rich Environment Probability”

Rolls the dice favourably for you.

Clive Robinson • October 29, 2022 5:23 AM

@ Reba, ALL,

“You missed one that seems obvious to me: switching to another implementation.”

Yes it’s possible, but…

In theory come Nov 1st there will be a seamless series of patches / upgrades, so time or more correctly the shortness of it comes into play.

Based on that you can make an argument –and some already have– that the time window is too short for attackers to find / reverse / use the vulnerability.

Which brings in the question of available resources within the time frame and how best to deploy them.

If the “they can not find / use” argument is true, and I’m not saying it is, then one option is the,

“Do nothing other than watch intently and pull the switch if things look hinky.”

It falls in line with the notion of a “target rich environment” and the number of potential attackers is very small, hence the probability of being attacked for most in the short time frame is low.

However it was not that long ago about teb months, that the “Online World” apparently very nearly died due to Log4J and the resulting Log4Shell vulnerability.

Of which the following was said[1],

“Log4Shell, an internet vulnerability that affects millions of computers, involves an obscure but nearly ubiquitous piece of software, Log4j. The software is used to record all manner of activities that go on under the hood in a wide range of computer systems.”

You could take out of that “Log4Shell”, and replace with “Open4Hell” or what every the new vulnerability will be named. And likewise replace “Log4j” with “OpenSSL 3.0”, oh and replace “to record” with just a simple “for” and it would be right on the button (so one “Press release intro written”).

Now “if” and it’s a very big “if” people have done not just “software inventories”, “dependency graphs” and the like that got pushed out from the Oval Office, then in theory they could pull out OpenSSL 3.x and drop in something else.

But really? One thing developers are known to do is “abuse interfaces” and sadly in many cases just “cut-n-paste example code” from the web or similar is not the least of what they do… So much so in fact you get,

https://www.openssl.org/policies/technical/api-compat.html

As a result with it’s warning of,

“No changes to existing public API functions and data are permitted. “

Is as much applicable to developers using OpenSSL as much as it is to the developers of the OpenSSL package. Many still have quite bitter memories of what happened in the history of SSL and the sense of betrayal etc that came out, and the long months trying to sort out the resulting mess.

So whilst I’m not adverse to people doing a “plug-n-play swap” to a different package (but not 1.1.1r[2]) the questions arise of,

1, Can they?
2, Correctly tested?
3, In the time frame?

And I’ll be honest my assessment in such a short time frame is “no” for just about everyone. Thus focusing resources where they can be most effective gives you broadly the two mittigation stratagies I outlined.

But I’m in no way saying that a modular “plug-n-play” framework that alows fast, safe, and secure swaps is a bad idea, I’ve been suggesting NIST gets it’s backside into gear and come up with such a set of standards to do so for most of this century. Because “embedded systems” in “humans and infrastructure” that have half century or more “in service” lifetimes and upto ten year development times is actually normal. So there will be people with medical electronics implanted in them towards the end of this century, which will be “insecure”… likewise the water, energy, road, manufacturing infrastructure we mostly unknowingly rely on will be insecure and infesable to upgrade. Both “humans abd infrastructure’ are currently not in any realistic time frame upgradable, so unless we have the standards soon not only us but our children, and grandchildren are going to be in a whole world of hurt…

[1] Log4Shell,

https://theconversation.com/what-is-log4j-a-cybersecurity-expert-explains-the-latest-internet-vulnerability-how-bad-it-is-and-whats-at-stake-173896

Was perhaps a little more urgent in that it came into major world view with a “Proof of Concept” apparently much to the ire of parts of the Chinese Government. But it also caused jokes about the US President having to be woken from his Dracula like sleep in the crypt of the Whitehouse due to the severity of the problem.

[2] Under the openssl.org opening page at the time of this writing, you will find their latest news the latest of which for the “12-Oct-2022”, is the bland,

“OpenSSL 3.0.6 and 1.1.1r are withdrawn. New releases will be created in due course.”

So if the word “Comforting” drifts sarcastically into view…

Clive Robinson • November 1, 2022 8:11 PM

@ Gert-Jan, ALL,

Re : Standards as cyber-weapons.

You are only looking at one side of one of sever coins when you say,

“That the goal is to never create a newer version that is backwards incompatible.”

I’ll go through the flip side, and some of the others…

Thus the first important question is,

“What do you do when the older version is broken, insecure, or incompatible at the current “standards level”?

I’ve been making the point for all of this century…

That is the SigInt Agencies like the US NSA and UK GCHQ and the other Five-Eyes nations hqve populated the standards bodies and they act as “tag-teams” for each other to weaken or add faults to standards.

I’ve repeatedly said on this blog and other places that from a SigInt agency perspective they will attack,

1, Plaintext (Bob Morris confirmed this as did Microsoft file formats).
2, Implementations (AES with it’s time based side channels and paying RSA over DRNG confirms this).
3, Protocols (again AES and DRNG).
4, Standards (DRNG with dual eliptic backdoor).

The latter caused NIST to withdraw a standard and re-issue it.

Any software compliant with the old version of the standard is effectively incompatible with versions compliant with the new standard, and it’s important that they should be so.

The issue behind it all that is realy problematic is that of, what is known as an “instance” that is within a “class” of vunerability at any one point in time will be different at a different point in time.

Thus there are vulnerabilities that are “instances in classes” that are,

1, Unknown, Unknowns
2, Unknown, Knowns
3, Known, Knowns.

As time progresses things move from being Unknown-Unknowns, to somebody finding a first example instance in what is now a new class. Thus there will be more instances to be found in the now known class, so we have moved to the Unknown-Knowns state. Time progresses and eventually from an analysis perspective all the instance types in a class are found thus become known and we move to Known-Knowns.

But the process has two disadvantages,

1, It takes time to progress.
2, The process is unbounded.

So, there will always be unknown classes thus unknown instances of vulnerability in existing systems.

The implication of this is you have to either,

1, Update forever.
2, Kill backwards compatability.

We obviously can not update forever or even quite a short period of time, so we have to kill backwards compatability.

We’ve been through the “kill” Option with SSL in the past.

But there is a more general issue of some,

“Standards, protocols, or even inplementations, contain engineering modes that can be vulnerabilities.

These “Engineering Modes” or “Test Harnesses” are used to try and find faults when some item like SSL is used as part of a larger system. In the past this has resulted in “minimum crypto” being “OFF” or “Send Plaintext” which is equivalent to “No Security” which is bad enough, but atleast you have a chance of “catching it on the wire” by “instrumentation”.

Such modes are fine if you are “fault finding” but very bad news if it can be done behind your back… and in many older implementations this could be done via a “Man In The Middle Attack” and forced protocol negotiation of a “Fall-Back Attack” which is by default kept hidden from users “so they don’t get confused” (thus bug tech support etc).

All the attacker has to do is make the only protocol both the first and second communicating parties have in common is “plaintext” or worse some other now weak crypto protocol like say RC4, which won’t be anywhere as easy “to catch on the wire” (hence the “Eternal Vigilance” quote has sharp and persistent teeth).

The history of computer based crypto algorithms and modes defined in syandards is actually not very good. It’s about 1/4 century which in reality can boil down to as little as 1/10th of a century when you alow for product life times.

For instance there was a time when RSA 1024bit key was considered secure, we know know that it is not secure and can be broken. People have moved up to as much as 16384bit keys, but there are few implementations in use that can work with that many bits. Especially where it is most needed which is in embedded systems… It’s just one of many reasons I’ve been saying for a very long time now that NIST should put it’s “algorithm competitions” to one side and come up with a “framework standard” that makes the upgrading of products practical even if companies go out of business, thus killing off the orphaned product problem where products could have a half century exprcted “in service life” (think implanted medical electronics and infrastructure components such as “smart meters”).