Apple Zero Day Remains Unpatched

A recently disclosed kernel-level zero-day vulnerability in Mac OS X Yosemite and Mavericks remains unpatched, though reports say Apple is developing and testing a patch.

Luca Todesco, an 18-year-old security researcher from Italy, on Sunday dropped details and proof-of-concept code about the security issue shortly after he disclosed them to Apple.

Multiple requests for comment from Todesco went unanswered prior to publication. He rationalized on Twitter that his disclosure is akin to releasing details about an iOS jailbreak, for example.

“the developer has released information about the exploit to the general public” which is what happens every time someone drops a jailbreak

— Luca Todesco (@qwertyoruiop) August 16, 2015

The flaw has apparently been addressed in the El Capitan beta version of OS X, according to a Github post from Todesco. He also recommends running SUIDGuard, a tool developed by researcher Stefan Esser that makes kernel-level exploits difficult to pull off.

“SUIDGuard is a TrustedBSD kernel driver that implements several mitigations to protect against weaknesses in the operating system usually abused in exploits,” according to the SUIDGuard Github page.

El Capitan, which is expected to be released shortly, includes a new system-level security protection called rootless that denies users and processes access to system-protected folders.

Todesco’s exploit, called tpwn, chains together two vulnerabilities that affect memory processes in OS X 10.9.5 through 10.10.5 at kernel level that bypass existing mitigations such as ASLR. Once through the door, a hacker has root-level access to a vulnerable machine; the risk, however, is mitigated since a successful attack requires a user to execute a malicious application or download from the Web.

Late last week, Apple patched another zero day in OS X in the operating system’s dynamic linker DYLD. Esser, on July 7, said OS X 10.10 supported a new DYLD_PRINT_TO_FILE variable which lacked “safeguards” that are generally included when new variables are added to the DYLD.

“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 processDyldEnvironmentVariable() function,” Esser wrote. “However in the DYLD_PRINT_TO_FILE case the code was directly added to the _main function of dyld.”

Esser wrote that DYLD accepts the new variable even for restricted binaries such as SUID root binaries.

“This is obviously a problem, because it allows the creation or opening (for writing) of any file in the filesystem. And because the log file is never closed by dyld and the file is not openes with the close on exec flag the opened file descriptor is inherited by child processes of SUID binaries,” he wrote. “This can be easily exploited for privilege escalation.”