Pesky C and Memory … OpenSSL on the Naughty Step, Again!
Pesky C and Memory … OpenSSL on the Naughty Step, Again!
Eight CVEs!
OpenSSL provides a foundation part of cybersecurity on the Internet. But, can be buggy. In fact, it caused the HeartBleed bug, which nearly caused large parts of the Internet to be untrustworthy. Basically, though, it is the Swiss Army Knife of cybersecurity and is often the “go-to” place for testing cryptography outputs.
Now, seven memory bugs have been found and which can cause data leakages and Denial of Service (DoS) vulnerabilities. The patches are:
- OpenSSL 3.0 to 3.0.8.
- OpenSSL 1.1.1 to 1.1.1t.
- OpenSSL 1.0.2 to 1.0.2zg.
Basically, it is all to do with malloc() in C, and where memory is reserved for data. Overall, C does implement garbage collection for memory which isn’t used anymore. Thus a function might store a password in memory, and then when the function completes, it can leave the password in plain sight in memory. To overcome this, we should use the free() method, and which cleans up the data space that we are not using.
The memory-related bugs which has a high risk is CVE-2023–0286, and moderate risks are CVE-2023–0215, CVE-2022–4450, CVE-2022–4203, CVE-2023–0216, CVE-2023–0217 and CVE-2023–0401.
The two major problems are:
- NULL memory allocation. Another problem area is the use of NULL for memory allocation, and where the value of zero is treated as a memory address. A bug in the code can then make use of a pointer to memory, and which has not been allocated to any location, but has a NULL (or zero value). In most systems, the first page of memory are marked as unusable, and often causes a hardware error when accessed. Thus, an attacker could attack the bugs with a denial of service (DoS) and cause the program to crash.
- Invalid pointer. This relates to setting a pointer in C to a value that is not actually a memory location. This can cause major problems, as an intruder could write into areas of memory that are not allocated (and thus overwrite existing data stored in memory). An example of this may be to change an encryption key or modify the data contained in a digital signing request. The vulnerability can also lead to a crash if data is written to areas that are not allowed, and thus could be prone also to a DoS attack.
- Read buffer overflow. With malloc() we allocate a number of bytes for the storage of data. If the data is not checked for its size, an intruder can overflow the data into areas of memory than are used for other purposes. With Heartbleed, the program took 64KB of data from a data packet and wrote it into memory, and then read it back. An intruder, though, could send a data packet without any data, and thus there was nothing to write to memory, but where anything in the allocated memory will be read, and send back to the intruder.
- Use-after-free. This relates to when data is used by a function in the program, but not actually cleared when it returns. Another part of the program, though, may still be using the allocated memory.
The final bug is CVE-2022–4304 and relates to RSA decryption.
Conclusions
Pesky C … leaving it all up to the developer to do whatever they want. Perhaps, use Rust, and which slaps you on the hand if you do any nasty memory allocation things?
If you want to see how useful OpenSSL is, try here:
https://asecuritysite.com/openssl
and Rust: