OpenSSL fixes two ‘one-liner’ encryption bugs – what you need to know – Naked Security


Just over a week ago, newswires were abuzz with news of a potentially serious bug in the widely used cryptographic library OpenSSL.

Some headlines went so far as to describe the bug as a “perhaps worse flaw than Heartbleed”, which was dramatic language indeed.

Heartbleed, as you may recall, was a highly publicized data leak bug that went unnoticed in OpenSSL for several years before being exposed in a flurry of publicity in 2014:

In fact, Heartbleed can probably be considered one of the earliest examples of what Naked Security jokingly calls the BWAIN process, abbreviation of Bug with an awesome name.

This happens when discoverers of a bug aim to maximize their media coverage by coming up with a PR-friendly name, logo, dedicated website, and even, in one memorable case, a theme song.

Heartbleed was a bug that exposed very many public websites to malicious traffic that said, greatly simplified, “Hey”! Tell me you’re still here by sending this message: ROGER. By the way, return the text in a buffer 64000 bytes long.

Unpatched servers would dutifully respond with something like: ROGER [plus 64000 minus 5 bytes of whatever just happened to follow in memory, perhaps including other people's web requests or even passwords and private keys].

As you can imagine, once news of Heartbleed broke, the bug was easily, quickly, and widely abused by criminals and show-off “researchers.”

Bad, but not that bad

We don’t think these latest bugs reach that level of exploitability or immediate danger…

…but they are definitely worth fixing ASAP.

Interestingly, the two bugs fixed in this release are what we call in the title “one-liners”, meaning that changing or adding a single line of code fixes each of the holes.

In fact, as we’ll see, one of the fixes involves modifying a single assembler instruction, which ultimately results in only two bits being swapped in the compiled code.

The bugs are:

  • CVE-2022-2274: Memory overflow in RSA modular exponentiation. Fortunately, this bug only exists for computers that support Intel’s special AVX512 instruction set, in OpenSSL builds that include special-purpose code for those chips. The programmer was supposed to copy N bits of unsigned long integers (usually 32 or 64 bits each), but inadvertently copied N unsigned long integers instead, thus copying many more bits in total than the buffer had space for. The fix was to divide the total number of bits by the size of each unsigned longto calculate the correct amount of data to copy.
  • CVE-2022-2097: Data leakage in AES-OCB encryption. When using Intel’s special AES acceleration instructions (widely found on newer Intel processors), the programmer was supposed to encrypt N blocks of data by running a 1 to N loop, but ran it inadvertently from 1 to N-1 instead. This means that the last cryptographic block (16 bytes) of an encrypted data buffer could exit with the last data block still being the original plaintext.

Fixes are simple once you know what is needed:


The modular exponentiation code now converts a number of bits to a number of integers, by dividing the number of bits by the number of bytes in an integer multiplied by 8 (the number of bits in a byte).


The AES-OCB encryption code now uses a JBE (jump if less than or equal to) test at the end of its loop instead of JB (skip if below), which is the same kind of change as modifying a C loop to say for (i = 1; i <= n; i++) {...} instead of for (i = 1; i < n; i++) {...}.

In the compiled code, this only changes a single bit of a single byte, namely by changing the value of the binary opcode 0111 0010 (jump if below) for 0111 0100 (jump if less than or equal).


Fortunately, we do not know if the special encryption mode AES-OCB is widely used (its modern equivalent is AES-GCM, if you are familiar with the many variants of AES encryption).

Notably, as the OpenSSL team points out, “OpenSSL does not support OCB-based cipher suites for TLS and DTLS,” the network security of SSL/TLS connections is therefore not affected by this bug.

What to do?

OpenSSL version 3.0 is affected by these two bugs and gets an update from 3.0.4 to 3.0.5.

OpenSSL version 1.1.1 is affected by the AES-OCB plaintext leak bug and gets an update from 1.1.1p to 1.1.1q.

Of the two bugs, the modular exponentiation bug is the more serious.

Indeed, buffer overflow means, in theory, that something as basic as checking a website’s TLS certificate before accepting a connection could be enough to trigger Remote Code Execution (RCE ).

If you’re using OpenSSL 3 and you really can’t update your source code, but you can recompile the source you’re already using, a possible workaround is to rebuild your current OpenSSL using the no-asm config parameter.

Note that this is not recommended by the OpenSSL team, as it removes almost all assembly-accelerated functions from the compiled code, so may end up being noticeably slower, but it will eliminate unwanted AVX512 instructions entirely.

To remove only the offending AES-OCB code, you can recompile with the config parameter no-ocbwhich should be a harmless intervention if you don’t knowingly use OCB mode in your own software.

But the best solution is, as always: Patch early, patch often!


Previous An introduction to troubleshooting for software developers
Next Insurance Commissioner Donelon Addresses Citizens Website Issues