Joyent SmartOS Hyprlofs FS IOCTL Native File System name Buffer Overflow Privilege Escalation Vulnerability

Summary

An exploitable buffer overflow exists in the the Joyent SmartOS OS 20161110T013148Z Hyprlofs file system. The vulnerability is present in the Ioctl system call with the command HYPRLOFS_ADD_ENTRIES when dealing with native file systems. An attacker can craft an input that can cause a buffer overflow in the nm variable leading to an out of bounds memory access and could result in potential privilege escalation. This vulnerability is distinct from CVE-2016-9034.

Tested Versions

Joyent SmartOS 20161110T013148Z

Product URLs

<https://www.joyent.com/smartos&gt;

CVSSv3 Score

7.0 - CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

CWE

CWE-121: Stack-based Buffer Overflow

Details

Joyent SmartOS is an operating system deployed by Joyent to be used as a hypervisor like solution meaning virtual machines will run on top of the system itself. SmartOS is unique in the fact that it is based on a fork of Opensolaris. This leaves many vulnerabilities in the kernel due to the fact that it is not as actively developed as other operating systems. Hyprlofs is a file system specifically designed for SmartOS which allows the creation of new virtual file systems quickly and easily. This was developed and designed to help make their product, Manta, possible.

Most of the controls for Hyprlofs go through the Ioctl calls. An Ioctl is a control function that operates on various streams in this case a file descriptor to the file system. Looking further into that code we can spot the vulnerability. The beginning of the function is shown below.

illumos-joyent-master/usr/src/uts/common/fs/hyprlofs/hyprlofs_vnops.c

        static int
134     hyprlofs_ioctl(vnode_t *vp, int cmd, intptr_t data, int flag,
            cred_t *cr, int *rvalp, caller_context_t *ct)
        {
            int len, cnt, error;
            char path[MAXPATHLEN];
            char nm[MAXPATHLEN]; [1]

            ...
            if (secpolicy_hyprlofs_control(cr) != 0)
                return (EPERM);
            if (cmd == HYPRLOFS_ADD_ENTRIES || cmd == HYPRLOFS_RM_ENTRIES) { [2]
                if (model == DATAMODEL_NATIVE) {
                ...

                e = kmem_alloc(len, KM_SLEEP);
                if (copyin((void *)(ebuf.hle_entries), e, len)) { [3]
                    kmem_free(e, len);
                    return (EFAULT);
                }

                for (i = 0; i < cnt; i++) {
                    if (e[i].hle_nlen == 0 ||
                        e[i].hle_nlen > MAXPATHLEN) [4]
                        return (EINVAL);

178               if (copyin(e[i].hle_name, nm, e[i].hle_nlen)
                        != 0) {
                        kmem_free(e, len);
                        return (EFAULT);
                    }
183                 nm[e[i].hle_nlen] = '\0'; [5]

The code at [1] shows the declaration of the vulnerable stack buffer of size MAXPATHLEN, 1024. We see at [2] that if our command is HYPRLOFS_ADD_ENTRIES we continue into the vulnerable code path. Our data is first copied in at [3], and is then used for some set up. Later we see the user supplied name length is validated to ensure it is not too large for the buffer at [4]. The vulnerability is present because the check says greater than MAXPATHLEN instead of greater than or equal, resulting in a length that is one too large to be allowed. This results in a null byte out of bounds write at [5]. This vulnerability may be leveraged by an attacker to potentially increase privileges or as a denial of service.

Timeline

2016-12-01 - Vendor Disclosure
2016-12-12 - Public Release