An exploitable kernel memory leak vulnerability is exposed by the rmsock setUID functionality of IBM AIX 6.1 and IBM AIX 7.1. A specially crafted command line can cause a kernel memory leak, resulting in uninitialized kernel memory being exposed. An attacker can execute rmuser with an invalid socket address to trigger this vulnerability.
IBM AIX 6.1, IBM AIX 7.1, IBM AIX 7.2, IBM VIOS 2.2
4.0 - CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
CWE-200 - Information Exposure
It has been identified that the rmsock setUID binary can be manipulated by an unprivileged user into leaking uninitialized kernel memory. This can be achieved by manipulating the parameters that are passed to the rmsock setUID binary when calling it.
By calling rmsock with a memory address, the AIX kernel will attempt to close a socket at the specified location. In order to close the socket, the rmsock setUID binary makes a call to getkerninfo() with the user-supplied value. As a result, the AIX kernel then attempts to manipulate the supplied location in an attempt to close the socket. Where the address does not point to a valid socket, the kernel may copy values at the user-supplied address back to userland. As a result, the rmsock setUID binary will return an error message consistent with disclosing 64 bits of kernel memory.
A simple proof of concept of how an attacker may be able to trigger the condition can be seen below.
1) Identify the address that corresponds to a socket:
netstat -@aA | grep telnet
2) Observe the following:
Global f1000e00001e3bb8 tcp 0 0 .telnet *. LISTEN
3) Call the rmsock setUID binary on the identified address which corresponds to the socket*:
The socket 0xf1000e00001e3bb8 is being held by process 3997826 (inetd).
4) Call the rmsock setUID binary with an address that does not correspond to a socket:
rmsock 65535 tcpcb rmsock : Unable to read kernel address 01ffc0609c0000f8, errno = 4
Further details on the intended use case for rmsock can be found here: https://www.ibm.com/developerworks/community/blogs/cgaix/entry/rmsock?lang=en
2018-03-23 - Vendor Disclosure
2018-07-03 - Public Release
Discovered by Tim Brown of Cisco Security Advisory EMEAR