The most well-known cryptographic library in the open-source world is almost certainly OpenSSL.
First, it’s one of the most widely used, to the point that most developers on most platforms have heard of it even if they haven’t used it directly.
Second, it’s probably the most hyped, unfortunately because of a rather nasty bug known as Heartbleed that was discovered over eight years ago.
Despite being patched quickly (and despite reliable workarounds for developers who couldn’t or wouldn’t quickly update their vulnerable versions of OpenSSL), Heartbleed remains something of a “showcase” bug, notably because it was one of the first bugs to be turned into an aggressive PR vehicle by its discoverers.
With an impressive name, a logo all its own, and a dedicated website, Heartbleed quickly became a global cybersecurity super story and, for better or worse, became inextricably linked with mentions of the name. OpenSSLas if the danger of the bug remained even after it was excised from the code.
Life Beyond OpenSSL
But there are several other open source cryptographic libraries that are widely used in addition to or instead of OpenSSL, including Mozilla’s NSS (short for Network Security Services) and the GNU Project GnuTLSGenericName library.
It turns out that GnuTLS just fixed a bug known as CVE-2022-2509reported in the project security consulting GNUTLS-SA-2022-07-07.
This hotfix fixes a memory mismanagement error known as double-free.
Double-Free Explained
Simply put, a double-free vulnerability is created when a programmer instructs the operating system to allocate a block of memory for temporary use…
…and returns it so that it can be removed from the list of lent blocks to be freed up for use by other parts of the program…
…then accidentally asks the system to free the same block of memory again.
Ideally, the memory allocation software will detect that the block no longer belongs to the part of the program that “returns” it, will realize that the offending block has already been recycled, and will not deallocate it a second time, thus avoiding the risks of “freeing” him again.
Dealing gently with a proactively detected double-free is a delicate matter. The C function that returns memory is prototyped as void free(void *ptr); so you’re passing the address of a block you want to free, but not getting a return code. (AC function with a void the return value is what other programming languages call a procedure: it does something for you, but it has no way of reporting a result.) So even carefully written C code has no standard way of detecting that something has gone wrong in free(), and thus no way to handle the error trying to shut down properly. Unilaterally terminating the offending program is the only safe solution for the system.
But if the memory allocation doesn’t happen (perhaps because that same block has since been distributed to another part of the same program, so it’s back in the “loaned” list in exactly the same form as before), then bad things are likely to happen.
Notably, the memory manager can inadvertently and unexpectedly “confiscate” the doubly freed block of code that is now legitimately using it, and reassign it to another part of the program, possibly even malicious code that an attacker carefully timed to take advantage of it. of bad management.
So you could end up with two parts of the same program handling the same piece of memory.
Part of the program assumes that it can implicitly trust the contents of memory, because it considers itself the rightful “owner” of the block.
At the same time, another part of the program knows it can mess with the data (or be tricked into messing with it) in order to deliberately trip up the first part.
do the wrong thing do the right thing
Ironically, bug CVE-2022-2509 exists in the certificate verification code in GnuTLS.
(The irony, in case you were wondering, is that software that is generally insecure because it doesn’t bother to check for trusted TLS connections is safe from this security bug. specific.)
For example, when you visit a website (or other type of server) secured with TLS, the other end will usually send you a web certificate that asserts that the server is actually owned and operated by the organization you expect.
Of course, since anyone can create a certificate under any name they want, a raw certificate doesn’t tell you much, so the owner of the certificate usually has it digitally signed by a company to which your browser is already trusted.
In practice, certificates are usually signed by a certificate which is, in turn, signed by a certificate your browser trusts, but the end result is something called a chain of trust which can be safely traced to an already installed certificate in a list of so-called Trusted authoritiesalso known as Rootswhich is managed by your browser or operating system.
To simplify and speed up the certificate chain validation process, many servers do not simply send their own certificate and leave it up to the browser to “continue the chain” to a root of trust.
The server usually includes the chain of trust it relies on, which it only needs to construct once, so that your browser, or other software that verifies the certificate, can simply verify that the chain is digitally valid, then verify that the last certificate in the chain matches the one already trusted.
In this case, GnuTLS will correctly and securely validate the provided certificate, before freeing the memory block just used to store it.
But if the other end does not provide a pre-generated certificate chain, thus leaving GnuTLS to create and verify the chain on its own, then the GnuTLS code accidentally frees the memory used to store the provided certificate before starting the chain- verification process…
… then releases it again once the check is complete.
This causes a double free crash, which can lead to memory corruption, followed by a program crash.
Driving a crash to implant malware
Usually, or at least often, crashes cause behavior so wayward that the operating system detects that the offending program has lost control of the flow of program execution – for example, if the program jumps to a random memory address and tries to execute code from a block of memory that hasn’t been allocated at all.
In this case, the crash would cause a system error, and although this type of bug can be abused for what is called a Denied service (DoS), where the goal is simply to disrupt the attacked program, this does not lead to Remote code execution (RCE), where untrusted and unwanted software code is triggered instead.
But whenever there is a program crash that attackers can cause at will, based on unreliable data they provided themselves, there is always a risk that the crash could be guided in a way to misdirect the crashing program so that it jumps into the executable code provided by the attackers.
As you can imagine, attackers can often exploit these vulnerabilities to implant malware, either temporarily or permanently, since they can inject untrusted code into your computer without producing pop-up warnings first asking authorization.
What to do?
Update to last version of GnuTLS, which is 3.7.7 at the time of writing.
(This bug was apparently introduced in GnuTLS 3.6.0 and exists in all versions from there, up to and including 3.7.6.)
Note that many popular applications and programming toolkits include or can be designed to use GnuTLS, although you may not be aware of it, including but not limited to: FFmpeg, GnuPG, Mplayer, QEMU, Rdesktop, Samba, Wget, Wireshark and Zlib.
Many Linux or *BSD packages that use GnuTLS will rely on a core version maintained by your distro itself, so be sure to update as soon as your distro has that version available.
Good update!
Comments are closed.