It’s difficult to concentrate on all the other things you should, and normally would, be working on given the ongoing debacle produced by the seemingly omnipresent Log4Shell insecurity feature. Furthermore, the National Cyber Security Centre (NCSC) of the United Kingdom has warned people: “Remediating the Log4Shell vulnerability is inclined to take weeks, if not months, for bigger organizations.”

The following quotation comes from the NSCS’s advice for corporate boards of directors, in a section where senior management is advised to take actions to prevent cybersecurity workforce exhaustion.

In case you missed it, the legendary OpenSSL cryptography framework — a free and open-source software package that we imagine is far more commonly used than Log4J — also released upgrades this week. OpenSSL 1.1.lm replaces 1.1.1l, while OpenSSL 3.0.1 takes the place of 3.0.0.

The fact of the matter is that there are no CVE-numbered vulnerabilities listed in the OpenSSL 1.1.1m latest update, implying that while this update is both desired and vital, you don’t really need to label it critical just yet. Those of you who already upgraded to OpenSSL 3 should really be aware that OpenSSL 3.0.1 addresses CVE-2021–4044 security flaws.

There are no reported exploits for this flaw that we’re aware of, however as the OpenSSL documents point out: “The error code which may be displayed as a result of the bug will be completely unpredictable, and as a consequence, applications might not even function properly.”

The specific behavior will vary depending on the application, but it may cause crashes, indefinite loops, or other erroneous responses.

In concept, a well-written program should not be exposed to this flaw, which is triggered by “error conflation,” which is really just a nicer way of saying “we provided you the incorrect results.”

Briefly said, some internal OpenSSL problems don’t get handled appropriately — for example, a legitimate but unlikely error, like running out of memory, or a vulnerability elsewhere in OpenSSL that causes an error where there wasn’t one. Instead of returning to your application immediately, these errors are “remapped” when they are transmitted back up the OpenSSL call chain, where they eventually appear as a whole other type of problem.

The first time this flaw is detected, as explained in the OpenSSL advisory, is when an error, such as a memory error, is accidentally sent to you as a “you need to try this again” sort of error. In practice, you should presume that memory failures are unrecoverable, and your application should shut down as quickly and neatly as possible to avoid crashes or corruption, thus “trying this again” is almost definitely a bad idea.

The second option is if a different and recently-fixed OpenSSL bug, which isn’t good enough to justify a CVE by itself, causes the fake “you need to try this again” error although no mistake occurred. As you might expect, telling someone “you need to try this again” when all that will happen is that they might make another similarly inaccurate error is a prescription for disaster.

Countermeasures

If you’re using OpenSSL 1.1.1, you’ll need to upgrade. Your clients may legitimately anticipate you to fix it, but if you’re still fighting Log4Shell, we hope they’ll be patient and not demand it right away. Nevertheless, be mindful that automated vulnerability scanning solutions that “find” flaws solely based on firmware version sequences, instead of assessing whether a bug is genuinely exploitable or even accessible in the code they’re “analyzing,” may generate disturbing alerts. Be prepared for it.

If you’re using Open SSS 3.0.0, you’re in luck. This issue is likely not critical, and it might not have been triggered in your code, but for the sake of clarity, the easiest and fastest answer is to patch it.

If you’re a developer, this is for you. From the moment where the error occurs to your log file or terminal, try to keep and display accurate error messages. Because you’re misguiding your users, “clumsy” error reporting causes debugging headaches. In the worst-case scenario, inaccurate or misleading error signals might lead to risky decisions elsewhere in the code, such as pushing on purposely while memory is running out. Because a reported “issue” that doesn’t truly exist can never be “fixed,” avoid indicating faults with values that could develop legitimately.