Reversing Apple’s syslogd bug

Two days ago El Capitan 10.11.3 was released together with security updates for Yosemite and Mavericks. The bulletin available here describes nine security issues, most of them related to kernel or IOKit drivers. The last security issue is about a memory corruption issue on syslog that could lead to arbitratry code execution with root privileges. I was quite curious about this bug mostly because it involved syslogd, a logging daemon.

This post is about reversing the vulnerability and finding how it could be exploited. Unfortunately for us Apple is very terse on its security updates – for example they say nothing about if it is exploitable on default OS X installations or requires particular conditions. As we will see later on, this bug is not exploitable on default OS X installations.

While Apple makes available the source code for many components used in OS X, most of the time there is a significant delay so we need to use binary diffing to find out the differences between the vulnerable and updated binary. The usual tool for this purpose is BinDiff but there is also a free alternative called Diaphora made by Joxean Koret. Both tools require IDA and on this post we are going to use Diaphora. For this purpose we will need a copy of the vulnerable and patched binaries. The easiest way is to copy the syslogd binary (found at /usr/sbin/syslogd) before the updates are installed (usually it’s a good idea to have virtual machines snapshots for each version) and then after (or just extract the new binary from the update packages – El Capitan, Yosemite, Mavericks). This post will focus on Yosemite binaries.

Diaphora essentially works by generating a database and then comparing its contents. Comparing the 10.11.2 and 10.11.3 syslogd binaries gets us the following warning from Diaphora:

identical_callgraph
This means that both binaries are very similar so we should expect minimal changes between the two. Only one change is detected and its output is below.

patch_diffThe change is quite subtle. The original code could be something like:

reallocf(pointer, value + 4);

And the patch something like:

reallocf(pointer, value * 4 + 4);

The syslogd source package for El Capitan 10.11.2 can be downloaded here. The easiest way to try to locate this function is to grep the code using the string “add_lockdown_session: realloc failed\n”, finding a single hit inside syslogd.tproj/dbserver.c. The source code for this function is: add_lockdown_session_codeThis makes it easier to observe the vulnerability. The patch is made on the reallocf() allocation size while the vulnerability is triggered when the fd variable is written into the lockdown_session_fds array. The allocation size used in reallocf() is wrong since it’s allocating memory just for the number of lockdown sessions instead of enough memory for each session. The following image taken from Zimperium’s analysis is a perfect illustration of the overflow and heap corruption.
Heap-overflow-out-of-bounds-write-because-of-invalid-size-calculation-during-reallocationAt the third connection the heap corruption is happening but from my tests more connections are required to make it crash (I get most of the time crashes in different areas than Zimperium but I was also testing against OS X).

The developer of this particular piece of code made a mistake, and the fix can be as simple as adding a set of parenthesis:

code_fix
C language is powerful but unforgiving of these small mistakes.

At this point we know where the vulnerability is and how it was patched. The next question is how do we reach this function? The following is the partial call graph for add_lockdown_session():

callgraph_add_lockdown_session
Judging by the initial function names the vulnerable function could be reached either locally (unix socket?) or remotely/locally (via TCP socket). The security bulletin mentions an attack from a local user. Looking at /System/Library/LaunchDaemons/com.apple.syslogd.plist configuration we can only observe the syslog unix socket:default_syslogd_socketsThis means that the default configuration in OS X is not vulnerable, unless the user changes it. Unfortunately for us Apple doesn’t mention this in the bulletin, which is indeed interesting information for example to anyone running old systems that can’t be upgraded.Let’s dig a bit deeper and understand what do we need to do to activate this feature in OS X so we can try to reproduce the vulnerability. The remote_acceptmsg_tcp() function seems like a good candidate to trace back. Looking it up on source code we will find an interesting function:remote_init_sourceThis is the function that will activate the remote feature which allows us to reach the vulnerable code. The #ifdef mean that we can check the binary to see if they were compiled or not into the final binary.remote_init
The disassembly output of remote_init() shows that only remote_init_tcp() was compiled, meaning that we can reach the vulnerable code via tcp sockets, either locally or remote depending on user configuration. The remote_init_tcp() function takes care of creating and binding the listener socket and is the one calling remote_acceptmsg_tcp() we saw in the first callgraph using Grand Central Dispatch.remote_init_tcp_sourceWe still don’t know how to activate the remote feature. Next step is to see who calls remote_init(). There are two calls but the most interesting is init_modules().init_modules_sourceThe remote module support will be compiled into syslogd binary if the target is not the iOS simulator and the default enable or disable status depends on the remote_enable local variable. Its default value is zero, meaning the remote feature is disabled by default. This is another strong clue about a default OS X not being vulnerable.
Finally init_modules() is called by main(), where we can find the final clues about how to activate this feature.main_sourceInside main we can observe interesting things and finally be sure if OS X is vulnerable on default installation or not. The first thing we can observe in the above code snippet is that the remote feature is enabled by default on the embedded OS, usually meaning iOS and AppleTV. Next there is an option “-config” that also enables it if the iphone option is selected. Last is the undocumented “-remote” command line option, which can enable the remote feature on any Apple operating system.

To activate the feature we need to edit syslogd launchd configuration file found at /System/Library/LaunchdDaemons/com.apple.syslogd.plist (usually in binary format but can be converted using “plutil -convert xml1 filename“). The ProgramArguments and Sockets keys need to be modified to the following:

launchd_configBecause launchd controls the sockets we also need to configure the socket where syslogd will be listening for the remote option (#define ASL_REMOTE_PORT 203).
After we modify the plist and reload syslogd we can finally connect to port 203.

telnet_asl_remote_exampleThe vulnerable code path is triggered using the watch command. If we attach a debugger and insert a breakpoint in the vulnerable add_lockdown_session(), the breakpoint will never be hit when we select the watch command. This is the code inside session that calls the vulnerable function:call_vulnerable_functionThe WATCH_LOCKDOWN_START is only set in one place inside session:set_watchdown_flagThe SESSION_FLAGS_LOCKDOWN is a flag passed on the only session argument.
And we can finally observe and conclude why the security bulletin talks about a local user:remote_acceptmsg_sourceThis means that the SESSION_FLAGS_LOCKDOWN flag is only set on local connections and never on remote tcp connections, the only feature we have enabled in OS X syslogd binary. The functions who call remote_acceptmsg() show it clearly.remote_acceptmsgs_sourceThe conclusion is that there is no code path to trigger this bug in OS X, even if the user configures the remote feature. To test the bug and observe it in action the only way is to attach to the syslogd binary (or patch it) and remove the above condition (we can also patch inside session but here is easier). Next we just need a small tcp client that sends a few connections to the port 203 and issues the watch command. Sooner or later the syslogd binary will finally crash.
The vulnerability also doesn’t seem easy to exploit because we don’t have much control over the fd variable that is overwriting the allocated array.

One final note is that the vulnerability was only patched in El Capitan but not included in Yosemite and Mavericks security updates. While we have just seen that even on El Capitan there is no code path to the vulnerable code it is weird that the older versions weren’t also patched. Apple security policy is still confusing most of the time.

So after a long post we can finally conclude that there is nothing really interesting about this vulnerability in OS X (and also iOS given the potential barriers to exploitation). It was just an interesting reverse engineering and source code analysis exercise to understand the vulnerability impact in OS X. This exercise wouldn’t be needed if Apple just published more relevant details on its security bulletin.

Thanks to pmsac for draft post review and exploitation discussion (also to qwertyoruiop and poupas).

Have fun,
fG!

P.S.: The tool used to generate the call graph is Understand from http://www.scitools.com. It’s a great tool for browsing and auditing large projects.

Gatekeerper – A kernel extension to mitigate Gatekeeper bypasses

Last month Patrick Wardle presented “Exposing Gatekeeper” at VB2015 Prague.
The core of the presentation deals with Gatekeeper bypasses originating in the fact that Gatekeeper only verifies the code signatures of the main binary and not of any linked libraries/frameworks/bundles.
This means it is possible to run unsigned code using dynamic library hijacking techniques also presented by Patrick in code that should be protected by Gatekeeper. His exploit uses an Apple code signed application that is vulnerable to dylib hijacking and his modified to run unsigned code when downloaded from the Internet. In this scenario Gatekeeper enters into action and should verify if the download is code signed (assuming the default OS X scenario where it is enabled). But in this case Gatekeeper will fail to verify the linked code and effectively is bypassed.

The core of the problem is that Gatekeeper only deals with the main binary code, and never verifies any linked code. This is obviously a flaw and hopefully a fix by Apple should be out sooner or later. Meanwhile we can try to build ourselves a fix using the TrustedBSD framework. For this I created Gatekeerper, a proof of concept kernel extension for Yosemite 10.10.5 (can be easily adapted to work with El Capitan, but I don’t want to release that code).
Continue reading

London and Asia EFI monsters tour!

Finally back home from China and Japan tour, so it’s time to finally release the updated slides about EFI Monsters. After Secuinside I updated them a bit, fixing stuff I wasn’t happy with and adding some new content.

The updated version was first presented at 44CON London. I had serious reservations about going to the UK (not even in transit!) but Steve Lord and Adrian charm convinced me to give it a try. 44CON was great and it’s definitely a must attend European conference. It has the perfect size to meet people and share ideas. I prefer single track conferences, dual track is the max I’m interested in. More than that it’s just too big, too messy, too many choices to be made regarding what to see.

A big thanks to everyone at 44CON who made it possible!

Next was SyScan360 in Beijing. It was the fourth time it happened, and my third time in a row. I do like very much to go there because even with language barriers you can feel what’s happening there. Bought a bunch of (cheap) hardware gear made by 360 Unicorn team. Their “usb condom” is super cheap and super small. Also bought a network tap and a USB to serial (don’t really needed it but it was damn cheap). The SyScan360 badge as usual was super fun, this time with a micro Arduino, Bluetooth and LED modules. Conference went pretty smooth and had lots of fun. They had a gigantic LED panel where slides were displayed at. That was some gigantic TV they had there :-)

Big thanks to everyone involved in SyScan360 2015.

Last stop, was CODE BLUE happening in my current favorite city outside Portugal, aka Tokyo. Third time happening, my second in a row. Organization is top notch, everything goes smoothly. Congrats to Kana, El Kentaro, Tessy, and everyone else involved.
This year it had two tracks, and a lot more attendees. It’s definitely a conference to put on your calendar. The audience is super interested in learning. Japan is lagging behind in terms of security so they are keen to finally catch up.

Some people approached me and shown some interested about (U)EFI security. This is great, that was the goal of this presentation, to show people (U)EFI research isn’t that hard and that it is really important its issues start to be fixed. We need to start building trustable foundations and not try to solve everything in software on top of platforms we can’t really trust.

Last conference for the year is No cON Name happening in Barcelona next December.

For next year I already got something that hopefully I’ll be able to present at SyScan360 Singapore. Their CFP is open and you should definitely think about submitting.

There were minor changes between 44CON and SyScan360/Code Blue slides. The latter included more references than 44CON version and minor fixes.

Have fun,
fG!

Slides:
44Con 2015 – Efi Monsters.pdf
SyScan360 2015 – Efi Monsters.pdf
CodeBlue 2015 – Efi Monsters.pdf

Rootfool – a small tool to dynamically disable and enable SIP in El Capitan

El Capitan is finally released and System Integrity Protection aka SIP aka rootless is finally a reality we must face. Let me briefly describe SIP (technical details maybe in another post, now that El Capitan is final and out of NDAs). This post by Rich Trouton contains a very good description of its userland implementation and configuration.

What is SIP anyway?

The description that I like to use is that SIP is a giant system-wide sandbox, that controls access to what Apple considers critical files and folders. One of the reasons for this is that most of kernel side SIP implementation exists into the Sandbox.kext, the same TrustedBSD kernel extensions that implements OS X sandbox mechanism.

For example, if we try to write to /System folder we get the following result:

sh-3.2# touch /System/test
touch: /System/test: Operation not permitted

And in system logs:

12/10/15 17:27:20,650 sandboxd[120]: ([424]) touch(424) System Policy: deny file-write-create /System/test

In practice it means that even with root access we are unable to modify those critical files and folders.
Continue reading

Writing Bad @$$ Lamware for OS X

The following is a guest post by noar (@noarfromspace), a long time friend.
It shows some simple attacks against BlockBlock, a software developed by Patrick Wardle that monitors OS X common persistence locations for potential malware. The other day noar was telling me about a few bypasses he had found so I invited him to write a guest post.
The title is obviously playing with one of Patrick’s presentations. I met Patrick at Shakacon last year and this is not an attempt to shame him (that is reserved mostly for Apple ;-)). It just illustrates the problems of building defensive tools and how much trust you put on them. By personal experience I can tell you that building a security product is a much harder task than what you might think initially.

Disclaimer: we both work for an endpoint software company. Together with another colleague I wrote an OS X version from scratch. I know very well the insane amount of problems that need to be solved, and they never end. When you build something you are always at mercy of potential security problems, we are no exception. Humans make mistakes. Offense is way easier ;-).

Anyway, enjoy it and hopefully learn something new!
Thank you noar!
fG!

I remember those days when there were only 3 or 4 security software editors for OS X. As the threat counts increased, the market grew up too. Many products are now selling you a feeling of being secure: most of them are post-mortem detection tools, and none is re-inventing the security paradigm.

This dinosaur fight left some room for an altruistic new hype: free – but not open source – security tools. Should we trust them blindly?

I am dedicating this post to HGDB, a former colleague and friend. Your sudden departure is leaving us in an infinite sadness. May you rest in peace.

BlockBlock

New utilities are emerging to free the user from major companies subscription fees, like the recently acquired Adware Medic or Objective-See tools KnockKnock and BlockBlock. So I had interest in reversing Patrick Wardle’s BlockBlock, a self-proclaimed continual runtime protection.
Continue reading

BSides Lisbon and SECUINSIDE 2015 presentations

I guess my goal for the remaining 2015 of not doing any presentations will not happen.
Two weeks ago I presented at BSides Lisbon 2015 and last week at SECUINSIDE 2015.

I’m very happy to see BSides Lisbon returning after the first edition in 2013. Congrats to Bruno, Tiago, and the rest of the team for making it happen. It’s still a small conference but I’m glad they are making it happen, and I will always do my best to help the Portuguese scene going forward. Everything went pretty well and met some new cool guys. I hope the conference returns in 2016 and keeps growing. Maybe someday it can mutate into something independent of BSides and on its own. Portugal is a great country for conferences, I’m just not the right person to start one, but I’ll definitely help my best anyone who wants to give it a shot.
The presentation is the same as CodeBlue and SyScan since the CFP happened a few months ago. Nothing new in the slides, a fix here and there.

The next was SECUINSIDE in Seoul. This is a very special conference to me because it was the first ever conference I presented at, back in 2012. I never had any plans to ever present at security conferences. I liked my low profile and this blog was good enough to spread the knowledge I wanted to. But I try to be flexible and always open to new adventures, so at the time I accepted HiTCON invitation (they were the first ones) and then SECUINSIDE’s invitation. SECUINSIDE was happening first so at the time I created a different presentation. It was a crazy trip because I did a Porto – Seoul roundtrip, and four days later I went to Taiwan. That was some crazy jetlag!
So this year I went back to SECUINSIDE. Thanks to beist, Ryan, trimo, and everyone else for the great time in Seoul.
The presentation is a new one, made in just a week. It’s essentially an introduction to EFI reverse engineering and hunting for EFI rootkits.

I received yesterday the good news that I was accepted to do the same presentation at 44Con. This is great and I will have enough time to improve the slides. Probably add some new content and tools, since there is good stuff expected out of Thunderstrike 2 presentation.

And here they are:

BSides Lisbon 2015 – BadXNU, A rotten apple!

SECUINSIDE 2015 – Is there an EFI monster inside your apple?

As usual, enjoy and have fun.
fG!