The exploits for the IBM AIX vulnerabilities mentioned in this security research series can be found on the Rhino Security GitHub page.

During a recent network penetration test, we had stumbled upon an instance of IBM AIX running behind an important e-commerce endpoint. While much of the environment was made of Linux servers, what stood out to the team was the age of the AIX server – much older than the other systems, it was likely a remnant of an earlier environment. With few other services available, we turned our attention to zeroday development in the proprietary UNIX system.

As technology and security enthusiasts, we knew this was going to make for an exciting engagement.

Advanced Interactive eXecutive (AIX) is a proprietary operating system based on UNIX System V and in close relation to its modern day cousins: BSD, Solaris and HP-UX. Since its début in 1986, AIX has been a fundamental element of IBMs enterprise product line, being available on a variety of IBM hardware platforms. It was initially developed for the IBM 6150 RT workstations running on the RISC processor, now being geared towards the POWER7/8 architectures.

Although its market share has dipped in the last decade, AIX’s development team has continued to advance its capabilities, with version 7.2 (Rel. 2015) bringing in Live Kernel Updates, POWER7 and a host of modern advancements. AIX also touts a number of engineering feats, being the first operating system to implement Journaled File System (JFS), and integration of processor and disk virtualization. It is perhaps one of the more mature operating systems on the market, and used in several of the world’s largest computing clusters.

To minimize risk to the client’s production server, we opted on replicating the target by renting an AIX instance which matched the same version and patch set. This allowed us to focus on vulnerability discovery and exploit development in a test environment, eliminating restrictions or risk of crashes during our research phase. Our testing environment was installed with AIX 7.1 (7100-04).

One of the first steps we took before auditing our fresh AIX installation was to study recent security advisories and zeroing in on any potential trends and patterns, which may be leveraged during discovery and exploit development. This is an essential step when dealing with proprietary software with a limited attack surface.
With a few candidates at hand, we began to reverse engineer the security patches and fixes distributed by IBM for the following CVEs:

CVE-2009-1786: IBM AIX libc MALLOCDEBUG File Overwrite Vulnerability
CVE-2009-2669: IBM AIX libC _LIB_INIT_DBG Arbitrary File Creation Vulnerability
CVE-2014-3074: Runtime Linker Allows Privilege Escalation via Arbitrary File Writes In IBM AIX

The fundamental problem between the aforementioned vulnerabilities is specific to programming logic flaws in IBM’s C library (libc) with regard to handling debug and malloc statistic output file creation.

To put it simply, AIX had implemented tools for developers to access during application runtime which allowed them to track potential issues with their code or memory usage, and allowing users to save the output into files.

Since the output file locations are user-controlled by means of environment variables (MALLOCDEBUG, _LIB_INIT_DBG and MALLOCBUCKETS) it was possible for unprivileged users, to create privileged files when debugging SUID binaries. IBM had patched this problem in the past, as evident by the associated CVEs, however we have determined the patches to be incomplete in at least two cases.

The lsmcode binary on AIX is used to display microcode and firmware levels of the systems adapters and devices.

Description: “The lsmcode command when run without any flags, displays the platform system firmware microcode level and the service processor microcode levels, if supported. Not all systems contain a service processor, nor do all systems support displaying the system processor level. Information on a specific device is displayed with the -d flag.

If you run the lsmcode command with the -r or -c flag, it displays the microcode levels in a printf format; that is, not a menu. This method is preferred if running lsmcode from a script.”

The lsmcode binary stood out as a potential attack vector specifically because it is software which requires quite a bit of privilege to access hardware based information that most of the other applications do not need. It is this feature, and programming flaws in the code itself, which allowed us to discover the first privilege escalation bug during our audit.

AIX provides developers with at least three separate malloc policies, Yorktown (default), Watson and Malloc 3.1. Applications which issue large amounts of small allocation requests can make use of the buckets allocator extension. One important feature that developers can make use of when utilizing MALLOCTYPE=buckets is the creation of statistics files for debugging and analysis purposes.

When CVE-2014-3074 was first disclosed, a large percentage of SUID binaries were vulnerable to privilege escalation attacks. IBM released a set of patches to combat the matter by dropping privileges before files were created, and if the specified file destination was privileged, or the user lacked permissions to create the file, then the buckets statistics would be displayed to standard output instead.

Although most of the applications on AIX had been patched against this specific problem, lsmcode would set its effective user identifier to root before the buckets file was created, thus reintroducing the original vulnerability and bypassing, or breaking the patches released by IBM.

In at least 29 separate instances along lsmcode’s program flow we see the setting of effective user id to root, prior to the malloc bucket statistic writes to file:

Using Korn shell’s little known SUID profile (/etc/suid_profile) feature, we were able to execute a set of arbitrary commands as root upon the next execution of a SUID binary. In our case, we decided to execute the ibstat binary (/usr/bin/ibstat) which has the required privileges, and has a low execution time and footprint.

This escalation point worked well since the vulnerability in question allowed us to create arbitrary, root-owned files inside of privileged directories. The exploitation process went as follows:

1. Export MALLOCBUCKETS environment variable, specifying the bucket statistics file as /etc/suid_profile
2. Set umask to 000, so that /etc/suid_profile would be writable
3. Execution of lsmcode, in turn creating our arbitrary bucket statistics file
4. Overwrite /etc/suid_profile, removing statistics from interrupting escalation flow
5. Adding arbitrary payload to /etc/suid_profile
6. Execute SUID binary, thus and consequently executing payload inside of /etc/suid_profile
7. Rootshell is saved into /tmp and ready for use

CVE-2016-3053 Proof of Concept Exploit Code on GitHub

As a consequence of our research into lsmcode, we had also identified another binary which had flew under the radar for the previous security patches.

The binary in question is lquerylv (CVE-2016-6079), which is part of the LVM package. It is generally used to query information from the Logical Volume Manager, and is one of the few LVM packages with SUID access that is also world executable.

The vulnerability details, escalation and PoC are similar with a slight difference – this vulnerability actually goes all the way back to AIX 5.3 and is exploitable using all three previously mentioned CVEs – two debugging facilities and the malloc bucket statistics file overwrite issue.

In patching AIX against the lsmcode vulnerability, lquerylv was also patched and you can find our PoC attached alongside this report.

PoC screenshot:

CVE-2016-6079 Proof of Concept Exploit Code on GitHub

As a security assessment firm, Rhino Security Labs invests heavily in research, both to improve the security of our clients and the community as a whole. As AIX is an important platform for many of our enterprise components, we are continuing our research in this area and expect to have additional releases in the coming months.

We’d also like to thank the AIX development and AIX security teams at IBM, who were very responsive to our outreach, and helpful in getting these vulnerabilities corrected. We look forward to working with them again

May 27, 2016 – Initial disclosure to vendor
June 06, 2016 –Vendor response
June 29, 2016 – Call to discuss vulnerability
August 22, 2016 – Followup with Vendor
November 2, 2016 – Vendor advisory issued

http://aix.software.ibm.com/aix/efixes/security/lsmcode_advisory2.asc

http://aix.software.ibm.com/aix/efixes/security/lquerylv_advisory.asc

UPDATE 11/28/2016:

After a discussion with Tim Brown at Portcullis Security, we wanted to clear up any confusion or questions researchers or AIX users may have had concerning the issues detailed in this post.

IBM had patched a security issue in their malloc implementation, as noted in our original post, with CVE-2014-3074 http://aix.software.ibm.com/aix/efixes/security/malloc_advisory.asc. Although the patch seems to have fixed the issue for the majority of SUID binaries, lsmcode and lquerylv remained vulnerable due to potential factors, including regression.

Furthermore, we had determined that lquerylv also allowed attackers to escalate privileges, as noted in our original post, with CVE-2009-1786 http://aix.software.ibm.com/aix/efixes/security/libc_advisory.asc and CVE-2009-2669 https://techblog.mediaservice.net/2010/01/cve-2009-2669-exploit/ reported by iDefense, and Marco Ivaldi (raptor) respectfully.

Our Proof of Concept exploits made use of the original attack vectors set forth by the aforementioned CVEs, to escalate privileges on systems as old as 5.3, and as recent as 7.2.0.1. Fortunately, with CVE-2016-3053 http://aix.software.ibm.com/aix/efixes/security/lsmcode_advisory2.asc, the core issue seems to have been resolved. Will post any updates with new information as they come.