Apple Fun

We thank everyone who has contributed, as well as those who donated to the project and sent nice feedback. We also thank the zealots, who made our day every time they blogged and commented about us. We would like to thank Apple for making this month a smooth one.

Last but not least, we will stop disclosing (although KF might continue releasing issues) any further information related to OS X security. Full disclosure isn't good. Feeding the security industry neither. Those who have criticized the project actually feed from it and people like us (we are evil, sure, and we can walk on water too). Without someone doing the real work, they would be selling peanuts at the Super Bowl; because they've got nothing but cheap marketing and Public Relations. They do little work besides talking to press and blogging about their synergistic-bullshit-fueled products. Some even lack enough decency for making subtle offers to work on the creation of problems for which they sell solutions.

OS X remains insecure, anyway. But now there will be less 'publicity hogging' about it. Finally, you can always keep an eye on our well respected friends at Matasano (no Tom Tom, though, but Dave and Dino are probably cool, heroes for not committing Seppuku while having a loose cannon as manager), who might keep the a-bug-per-year campaign.

Have fun, work independently and keep away from the "security industry". That doesn't mean you have to be a janitor at eEye, that would be cheating.

MOAB-31-01-2007: Stay tuned?

Multiple developers of Apple based software including Apples own developers seem to have a misunderstanding of how to properly use NSBeginAlertSheet, NSBeginCriticalAlertSheet, NSBeginInformationalAlertSheet, NSGetAlertPanel, NSGetCriticalAlertPanel, NSGetInformationalAlertPanel, NSReleaseAlertPanel, NSRunAlertPanel, NSRunCriticalAlertPanel, NSRunInformationalAlertPanel, and NSLog . For the sake of lulz alone a montage must ensue...

Further information:
Multiple Apple Software Format String Vulnerabilities
Application Kit Functions Reference

*this posting will be updated as time allows*

Apple iChat Bonjour functionality is affected by several remotely exploitable denial of service flaws which can be triggered via advertising presence services over multicast DNS.

Further information:
Apple iChat Bonjour Multiple Denial of Service VulnerabilitiesExploit: MOAB-29-01-2007.rbIn other news, "Craig Seeman cseeman (at) optonline.net" (author of Flip4Mac reviews) contacted us:

Hi,
regarding http://projects.info-pull.com/moab/MOAB-27-01-2007.html
This is what they're testing have found at this point: Flip4Mac has received reports of a QuickTime crash when playing a deliberately modified/damaged Windows Media file. There is no evidence that this has been or could be exploited to produce a security vulnerability. We have reproduced the crash and will include a fix for this in our next release.

Hmm, even Mr. Keller has kept out of his business (prolly learnt that integer overflows are useful to pop shells around, long after the initial DMG-related lessons). So anyway, better saved EIP overwrite for you:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xff806aa5
0xffff0ac7 in ___memcpy () at .../PrivateHeaders/i386/cpu_capabilities.h:228
228     in /.../PrivateHeaders/i386/cpu_capabilities.h
(gdb) i f
Stack level 0, frame at 0xbfffdc78:
eip = 0xffff0ac7 in ___memcpy (/.../PrivateHeaders/i386/cpu_capabilities.h:228); saved eip 0xdddeface
called by frame at 0xbfffdc80
source language unknown.
Arglist at 0xbfffdc70, args:
Locals at 0xbfffdc70, Previous frame's sp is 0xbfffdc74
Saved registers:
eip at 0xbfffdc70
(gdb) bt
#0  0xffff0ac7 in ___memcpy () at /.../PrivateHeaders/i386/cpu_capabilities.h:228
#1  0xdddeface in ?? ()

Sure we can fake the output. But we seriously have better stuff to do around. Like releasing a working exploit while you keep eating peanuts. Enjoy.

crashdump follows symlinks within the /Library/Logs/CrashReporter/ directory, allowing admin-group users to execute arbitrary code and overwrite files with elevated privileges. In couple with a specially crafted Mach-O binary, this can be used to write a malicious crontab entry, which will run with root privileges.

Apple crashdump Privilege Escalation VulnerabilityExploit: MOAB-28-01-2007.rb and vuln

Flip4Mac fails to properly handle WMV files with a crafted ASF_File_Properties_Object size field, leading to an exploitable memory corruption condition, which can be abused remotely for arbitrary code execution.

Further information:
Telestream Flip4Mac WMV Parsing Memory Corruption VulnerabilityProof of concept: MOAB-27-01-2007.wmv

Apple Installer fails to properly handle package filename strings. It's a affected by a typical format string vulnerability, which can lead to a denial of service condition or arbitrary code execution.

Further information:
Apple Installer Package Filename Format String VulnerabilityPetition Online: Assure OSX authentication dialog box authenticityPetition Online: Remove all admin->root authorization prompts from OSXSee: Sarcasm.

Also, many thanks to an anonymous supporter for donating to the project. We are at $568.73 USD now. We would like to note also that we don't endorse any actions taken against anyone who openly criticizes or disagrees with the project. Let's keep out of personal attacks, they don't bring anything interesting to the playground, and after all, there are plenty of ways to poke fun out of someone without resorting to dirty tricks. For instance, give a exploit a good use.

CFNetwork fails to handle certain HTTP responses properly, causing the _CFNetConnectionWillEnqueueRequests() function to dereference a NULL pointer, leading to a denial of service condition.

Further information:
Apple CFNetwork HTTP Response Denial of ServiceProof of concept: MOAB-25-01-2007.rb and MOAB-25-01-2007.cMany thanks to Craig Loomis, Greg Slepak and a previous supporter for donating to the project. The mark is at $472,93 USD now, so we are very close to the goal. Again, many thanks to everyone who has contributed, with both donations and feedback.

Software Update fails to properly handle the filename strings containing the swutmp extension. It's a affected by a typical format string vulnerability, which can lead to a denial of service condition or arbitrary code execution.

Further information:
Apple Software Update Catalog Filename Format String Vulnerability

QuickDraw is integrated in Mac OS X since very early versions, used by Quicktime and any other application that needs to handle PICT images. A vulnerability exists in the handling of ARGB records (Alpha RGB) within PICT images, that leads to an exploitable memory corruption condition (ex. denial of service, so-called crash, which can be used to gain root privileges in combination with MOAB-22-01-2007).

For further information:
Apple QuickDraw GetSrcBits32ARGB() Memory Corruption VulnerabilityProof of concept: MOAB-23-01-2007.pctApple has released a fix to MOAB-01-01-2007: Security Update 2007-001. They finally acknowledge the MoAB, with some PR crediting wizardry, aka 'let's mention but not explicitly say we are broken'. 22 days to fix a remote arbitrary code execution issue in one of their most extended products, distributed with working exploits for both Microsoft Windows and Mac OS X versions can be considered acceptable timing. Come on, it's not that difficult to change a strcpy() call... is it?

UserNotificationCenter retains wheel privileges on execution time, and still has a UID associated with the current user. Because of this, it> will attempt to run any InputManager provided by the user. Code within the input manager will run under wheel privileges. In combination with diskutil and a wheel-writable setuid binary, this allows unprivileged users to gain root privileges.

Further information:
Apple UserNotificationCenter Privilege Escalation VulnerabilityExploit: MOAB-22-01-2007.rbUpdate: updated exploit (now fat binaries are used, thus exploit should work on a system without XCode and related developer tools; source code is provided to avoid the usual FUD about alleged 'root kits' and non-sense), release information, etc. KF worked hard on getting stuff up due to connectivity issues. He deserves a thumbs-up from everyone.

The preference panes setuid helper, writeconfig, makes use of a shell script which lacks of PATH sanitization, allowing users to execute arbitrary binaries under root privileges.

Further information:
System Preferences writeconfig Local Privilege Escalation VulnerabilityExploit: MOAB-21-01-2007.rbThis week will be a really interesting one.

"Also, I’m pretty sure the SoD realized that writing to an SUID executable clears the SUID bit." -- Thomas Ptacek, Matasano.

Actually, the problem isn't 'writing to setuid binaries' but the fact that diskutil "repairs permissions", thus after replacing directories, binaries and any other file, the original modes are set back. In other words: replace setuid binary with one of your choice (given that a BOM/Bill of Materials file acknowledges it's existence and properties), run diskutil repair permissions, profit. It remains unknown if Thomas just didn't understand the point or simply continues his usual blog wagon. Probably both.

Yak yak yak. Get a job!

Apple iChat AIM URI scheme handling is affected by a classic format string vulnerability, allowing remote users to cause a denial of service condition or arbitrary code execution.

Further information:
Apple iChat aim:// URL Handler Format String VulnerabilityProof of concept: MOAB-20-01-2007.htmlAs contacting the "Heise Security" author of the now infamous, sensationalist accusations (which he promptly spread through Digg and every possible place around, with obvious malicious intent) didn't suffice, we are providing the full logs of the time frame (January 19 from 16:50 to 20:30) in which the Heise people involved in the article were repeatedly running CGI scans (which more than childish is actually purely script kiddie behavior, worth of the most disastrous years of every 12 year old starting in the so called "security scene" at some point) and testing/brute-forcing the URLs for forthcoming releases.

Apparently they don't realize that issues aren't uploaded until release time. But obviously they are in for the news and hype. Nothing else.

The Month of Apple Bugs: Hall of ShameAs promised, without entering any non-sense and useless claims/counter-claims cycle, we'll let everyone see how these people do 'professional journalism' and accuse others of 'childish and selfish' behavior when they are into certainly sketchy (read: illegal, dishonest, malicious) activities themselves.

Transmit does not allocate enough space when dealing with the string passed on via the ftps:// URL handler, leading to an exploitable heap-based buffer overflow condition.

For further information:
Transmit.app ftps:// URL Handler Heap Buffer OverflowProof of concept: MOAB-19-01-2007.htmlWe are releasing miscellaneous issues in order to have a slot full of interesting releases for this next week, that need to be properly worked on. To all of those asking 'Is that an Apple bug?' , please refer to the FAQ:

Are Apple products the only one target of this initiative?

Not at all, but they are the main focus. We'll be looking over popular OS X applications as well.

We may extend the month in order to release Apples-specific issues that can't make it within the 31 days time-frame. The problem of providing working exploits is that some minimal time is necessary to make them reliable and properly tested. We may release exploits for previous issues which only came with a proof of concept.

We can't do anything for preventing people to behave in a non-sense manner, except releasing more code for public consumption. And that's what we do, and will do. As we have already said, from now on, we won't be entering any claim/counter-claim cycle.

Many people have been speculating and obviously ranting about what 'responsible disclosure' means to them. Full disclosure doesn't do any good, neither reporting the issues to a careless vendor. The best practice is keeping the issues private. Less drama, more discreet, and certainly profitable if one decides to make a living out of it. Although, from times to times, when a false image of 'security' settles down thanks to deceitful vendor marketing, it's necessary to make public the information necessary to pop a shell in there.

And fortunately, everyone agrees that popping a shell is a Bad Thing (tm). Thus, most vendors quickly proceed to solve the problem when a click-and-point exploit is released. Except Apple, which instead forwards it to their PR arm. The security team at Apple may have nice people (and quite probably does) but their policies and security budget are just utterly broken. That's why issues remain unpatched, not even reviewed and obviously with no official statement.

Because for Apple, the only thing that matters is PR, sales and hype. And they don't want to admit it, thus the silence. The point is, we don't have any credibility. We are nameless. But our code does. And fixing the issues and publicly acknowledging them would confirm it.

rumpusd is vulnerable to different remotely exploitable heap-based buffer overflows, denial of service conditions and local privilege escalation issues. Due to the fact that Rumpus works under root privileges, successful exploitation by unprivileged users would allow a full compromise of the system.

Most of these issues are related to both FTP and HTTP request parsing, as well as insecure use of the system() function and incorrect permissions and/or handling of setuid binaries.

Further information:
MOAB-18-01-2007: Rumpus Multiple VulnerabilitiesProof of concept: MOAB-18-01-2007.rb

slpd is vulnerable to a buffer overflow condition when processing the attr-list field of a registration request, leading to an exploitable denial of service condition and potential arbitrary execution. It would allow unprivileged local (and possibly remote) users to execute arbitrary code under root privileges.

For further information:
Apple SLP Daemon Service Registration Buffer Overflow VulnerabilityProof of concept: MOAB-17-01-2007.rbThis issue was reported to Apple on 8/2/06 5:31 PM.