This post highlights several mistakes in the patches released for vulnerabilities affecting various services of HPE Intelligent Management Center, with a focus on its native binaries.

Author: István Kurucsai

During our work on N-day vulnerabilities, we encounter many different issues with security patches that can leave users of the affected product at risk even if they keep their systems up-to-date. Some fixes don’t attempt to address the underlying vulnerability but apply trivial changes that break the provided proof-of-concept exploit. Examples include removing the specific path used to trigger the issue while leaving others available or adding a layer of encryption to the communication protocol to which the exploit could easily be adapted. Other times, new vulnerabilities are introduced as a result of the code changes or previously unreachable vulnerabilities become exposed. Sometimes the fix is simply incorrect, e.g. it adds a new check for the wrong function call or with the wrong boundary conditions. There are cases where the original analysis of the vulnerability by the security researcher is incomplete, therefore the fixes and detection filters based on it are likely to be incomplete, too. And then there are the patches that don’t actually contain any relevant changes and the vulnerability remains exploitable while the issue is marked as resolved.

We encounter these cases almost weekly and have presented some examples on this blog, including one on the incomplete public analyses of an Advantech WebAccess vulnerability and one on the failed patch for Intel Security (McAfee) True Key.

Background

HPE Intelligent Management Center is a network management platform with a history of a wide range of vulnerabilities affecting it. It has a vast attack-surface, including web based components and native binaries implementing custom protocols. While the analysis was done on the Linux releases of IMC, it is important to note that the Windows and Linux versions are compiled from the same code base and share the same vulnerabilities.

Hiding Vulnerabilities

A common mistake we encounter during our day-to-day work is when a patch only removes a possible path for triggering the vulnerability instead of actually fixing the issue. A prime example of this is the attempts made at patching several issues affecting the dbman service, which is responsible for the backup and restoration of the databases used by IMC. The Linux version doesn’t have stack cookies and isn’t compiled as PIE. It listens on TCP port 2810 and expects a simple packet header consisting of an opcode and the data length, followed by a DER encoded ASN.1 message. Several vulnerabilities affecting it, including command injections, an arbitrary file write and a stack buffer overflow were published by ZDI in 2017 under the identifiers ZDI-17-336 through ZDI-17-343 and ZDI-17-481 through ZDI-17-484. These are quite similar in nature and close to each other in the code base. Let’s take a quick look at ZDI-17-336/CVE-2017-5820, titled Hewlett Packard Enterprise Intelligent Management Center dbman Opcode 10004 Command Injection Remote Code Execution Vulnerability.

Without going into too much detail, opcode 10004 corresponds to the BackupZipFile operation of dbman. After parsing the packet header and the ASN.1 message, control flow ends up in the CDbBackup::BackupOneLocalZipFile method, which constructs a command line that includes unescaped data from several message fields. This command line is then passed to the runCommand function, which is a wrapper around system, resulting in a command injection vulnerability. For the code snippet below, note that OneZipFileBackupObj is the parsed, unsanitized message from the packet.

The First Fix

In the HPE Security Bulletin corresponding to ZDI-17-336/ CVE-2017-5820, the first patched version is indicated as IMC PLAT 7.3 E0504P04. Looking at the supposedly patched 7.3 E0506 version, the CDbBackup::BackupOneLocalZipFile function seems identical, containing the same vulnerability. Examining its caller, BackupZipFile, the only difference is that a new function, dbman_decode_len, is invoked before the ASN.1 decoding. It’s a rather short method, decrypting the input using DES in ECB mode with a static key, which is liuan814 in version 7.3 E0506.

Examining the call sites for dbman_decode_len, they correspond to the opcodes implicated in the published vulnerabilities, meaning that this is the supposed fix for the issues. While this breaks exploits developed for previous versions of IMC, it’s in no way a proper patch. Simply encrypting the message with the static key enables exploitation of the original vulnerabilities.

The Second Fix

Looking at the newest version (7.3 E0605H05), the vulnerabilities are still present, unpatched. However, the encryption scheme was altered. dbman_decode_len became a simple wrapper around decryptMsg, which reads in keying material from two files in the IMC installation directory, common\conf\ks.dat and server\conf\imchw.conf. This is then used to derive a 256-bit IV and encryption key. These are passed into decryptMsgAes, along with the incoming data from the message, which decrypts it using AES_256_CBC and processing of the message continues as before.

The contents of the ks.dat and imchw.conf are randomly generated upon install or update of the product, therefore interacting with the handlers of the vulnerable message types is impossible without having access to those files. However, IMC has a significant attack-surface and any file read or write vulnerability can be turned into a command injection by leaking or overwriting the key files and triggering the original vulnerabilities. It should also be noted that both schemes are only applied to opcodes in which vulnerabilities were reported, other opcodes remain reachable as before.

New Vulnerability Introduced In The Second Fix

Looking at the decryptMsgAes function, it can be seen that a new vulnerability was introduced that results in a stack buffer overflow. For the code snippet below, note that src is the message read from the network, iEncLen is its length and strDecrypt is a heap allocated buffer in which the decrypted message is passed back to the caller. While there are no meaningful limits on the length of the input message, the code assumes that when decrypted, it fits into 4096 bytes. EVP_DecryptUpdate is part of the OpenSSL library and its documentation states that

the decrypted data buffer out passed to EVP_DecryptUpdate() should have sufficient room for (inl + cipher_block_size) bytes

The variable iEncLen corresponds to inl from the above quote. Since the input can be larger than 4096 bytes, a stack-based buffer overflow can be triggered on line 16 of the snippet below. There’s also the possibility for a heap buffer overflow on lines 20-21 but EVP_DecryptFinal will fail on incorrect padding and it’s impossible to create valid padding without knowing the IV and key. Even though the overflow contents cannot be controlled without knowing the AES key and IV, when combined with a file read or write vulnerability to leak or change the keying material, this issue could be turned into a reliable exploit.

This vulnerability remains unpatched for the time being.

Failed Patches

It’s not uncommon for us to see patches that attempt to solve the root cause of an issue but fail to do so.

Stack Buffer Overflow In tftpserver

The IMC suite includes a TFTP server, implemented by the tftpserver service, which is used to distribute configuration files for devices. The TFTP protocol supports setting the blksize option on a connection, which allows the client and server to negotiate a blocksize more applicable to the network medium. This option is also supported by tftpserver and can be set by a client to an arbitrary 4-byte value as can be seen on the code snippet from the 7.3 E0506 version shown below.

Later on, this value is used to determine not only the block size for the network transmission but also for the file read and write operations. In the TFTP::handleRRQ function, which is responsible for the handling of RRQs (file read requests by the client), the contents of the requested file are read in blksize sized chunks into a fixed size stack buffer of 10000 bytes, as shown below.

The TFTP::getFileData function reads in the requested number of bytes into the stack buffer using fread (code below). Since m_pkg_LimitSize is attacker-controlled, this results in a stack buffer overflow, exploitable by first uploading the payload file to the server using a write request, then setting the blksize option to a value larger than 10000 and requesting the same file via a read request.

HPE released a bulletin for the vulnerability, which states that it is fixed in version 7.3 E0605P04. Examining the updated tftpserver binary, the only relevant change seems to be in the TFTP::getFileData function, in which a check was added to ensure that the size variable passed in is below 65536 (0x10000), as shown on the following code extract.

There are multiple issues with this. As established previously, the buf argument points to a stack buffer that is 10000 bytes in size, so the check still allows an overflow of more than 50Kb. Besides that, the size argument is a signed integer and the blksize is also stored in a signed integer with an arbitrary value, meaning that negative values would also pass the check.

The latest version of IMC, v7.3 (E0605H05), was released on 08-Oct-2018 and still contains this incorrect fix.

The LogMsg Stack Buffer Overflows

An issue that took two iterations to patch properly is the vulnerability in the LogMsg method of the dbman service. The code of the function from version 7.3 E0504 can be seen below. As the name suggests, it’s used to log diagnostic messages. Accordingly, it has around 500 call-sites, many with arbitrarily long attacker-controlled data in the message, which can all result in a stack buffer overflow on line 10.

The vulnerability was patched in version 7.3 E0504P04, according to the HPE security bulletin. The fixed code is shown below and looks OK from a cursory glance, the length of the data written is limited by the use of the vsnprintf function.

However, the Msg buffer is then passed to the LogMsg_P function, which writes the data to the appropriate log file. It suffers from the same vulnerability as LogMsg. Even though the destination buffer on line 13 below is 8192 bytes long and the length of Msg is limited to 8192 bytes by the patch, there are up to a hundred bytes prepended to the actual message, so that the sprintf call can still write out-of-bounds. What is interesting is that triggering the original vulnerability is impossible without also triggering the one in LogMsg_P, meaning that the change probably wasn’t tested at all.

The second attempt replaced the sprintf call in LogMsg_P with an appropriately sized snprintf, actually fixing the issue. During the six-month period between the release of the two bulletins, IMC installations remained vulnerable to a supposedly patched vulnerability.

Conclusion

The N-day feed of Exodus provides detailed analysis of publicly disclosed security issues. These include many similar cases, where a vulnerability continues to pose a threat even after applying the vendor-supplied patch. It enables our customers to assess the real risks associated with vulnerabilities and implement proper detection and defensive measures. With our rigorously tested exploit code (supplied as part of the feed), organizations no longer need to rely on minimal proof of concepts that are usually available publicly. Our offerings can be leveraged by Red Teams to gain a foothold in the enterprise during penetration tests even when public exploit code does not exist or is simply unreliable.