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

In our previous blog-post, we started the conversation by working with vulnerabilities which had been previously reported but were reintroduced, either by regression or incomplete patching of the respective issues.

With this installment we are going to disclose a new vulnerability discovered during our initial research phase, which affects customers going back to at least AIX 6.1.

In a previous research engagement, we had discovered an unpatched vulnerability which allowed us to create privileged files across the filesystem. This lead us to focus on services and applications which interacted with the /var/spool directory tree. We spent a considerable amount of time cataloging binaries which we would audit for weaknesses, giving us a broad attack surface to explore.

The /var/spool directory structure maintains an important role for data processing across systems, applications and services as recent as today, and as far back as the conceptualization of UNIX.
To quote from the Filesystem Hierarchy Standard:

“/var/spool contains data which is awaiting some kind of later processing.
Data in /var/spool represents work to be done in the future (by a program, user,
or administrator); often data is deleted after it has been processed.”

One of the key elements in moving forward with this research was putting together a list of all applications and services which interacted with the /var/spool structure, analyzing them for potential security weaknesses and putting together proof of concepts, if possible.

Bellmail is a staple of the original AT&T UNIX files, and a core feature in AIX since at least version 6.1 and below. As outlined in IBM Knowledge Center article on Bellmail:

“The Bellmail command is the original AT&T UNIX mail command, which handles mail
for users on the same system and also for users on remote systems that can be
accessed by means of Basic Network Utilities (BNU), sometimes known as the
UNIX-to-UNIX Copy Program (UUCP).”

Bellmail stood out as a good candidate to audit and became high on the priority list because of the following items:

• It is set as SUID (root) and SGID (mail)
• It is installed by default with RBAC support
• After a bit of research, we found similarities between the output generated by Bellmail and mail.c from the UNIX System III source repository.
• mail.c from UNIX System III is 30+ years old. The fact that there is code re-use between AIX’s modern day Bellmail binary and UNIX System III code base may indicate potential security issues.

By following the program flow and reading the old SysIII/usr/src/cmd/mail.c sources, we predicted that we could create user-owned files inside of privileged directories (e.g. /etc). This vulnerability exists because the Bellmail binary:

• Executes with root (super user) privileges
• Does not drop above privileges
• Does a weak access() check to determine if the application can write into destination
• Writes email payload to user-defined file destination.
• Chowns destination file to getuid().getgid(), or similar

1) Send mail to a non-existent user
2) Within 60 seconds sendmail will bounce the email back
3) Execute Bellmail binary
4) While inside of the bellmail client, execute the following:
w /etc/suid_profile (or ’s’)

At this point, Bellmail will create /etc/suid_profile, handing over ownership of the file to the unprivileged attacker.

The next step for the attacker is to escalate privileges by injecting a sequence of commands which make up a payload, inside of etc/suid_profile. Read over our Proof of Concept exploit for reference.

GitHub: CVE-2016-8972.sh

In conclusion, additional research into the AIX platform has brought about another Local Privilege Escalation (LPE) vulnerability, this time in the Bellmail email binary. This is particularly high risk – even compared to our previous disclosures – due to Bellmail running in the hardened RBAC environment common among high-security organizations.

As always, thank you to IBM and the AIX team for the prompt response, coordinating proper disclosure, and working with us to get this issue corrected.

Stay tuned after the holidays, where Rhino Security Labs will post another AIX 0day blog disclosure.

Interested in our AIX security research? Contact us for more details on customized, highly-technical penetration testing services.

Nov 08, 2016 – Initial disclosure to vendor
Nov 09, 2016 – Vendor response
Nov 09, 2016 – Provided more details about issue, and Proof of Concept exploit
Nov 10, 2016 – Correspondence regarding Rhino Security Lab’s Vulnerability Disclosure Policy
Dec 14, 2016 – Status check
Dec 15, 2016 – Vendor advisory issued

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