Version: 1.0 (+leopard_ppc +leopard_x86 +tiger_x86 +tiger_ppc +win_xpsp2)
Wow the Macalope shocked Apple fans every with a statement that is reminiscent of hooves on a chalkboard.
You might be surprised to hear the Macalope agree with Maynor, but he's right.To start with, lets settle that dydl isn’t a library so Apple’s ASLR implementation is just peachy thread in his comments section. ASLR is more than just randomizing libraries. ASLR stands for Address Space Layout Randomization not Library Space Layout Randomization. Libraries are just one piece of the pie that also includes where the stacks and heaps are located and where the executable image gets based. Keep in mind that half implementing ASLR is about as useful as halfway closing a hatch on a submarine while its diving. The new QuickTime RTSP bug proved that by taking advantage of just a few components that are statically loaded in Vista. Therefore, you may get a gold star for effort in the end you can be sure that an exploit writer can take the time to find the overlooked areas.
The Macalope suspects that the free keggers the company throws for security professionals and, well, everyone and their alcoholic mother don't hurt, either.Ah there is the Macalope we know and love. If somebody says Microsoft did something right they must be bribed. Sorry, that’s not the case, I just think some simple things they have done will increase the overall reliability and safety of their applications. Take the Security Development Lifecycle and its list on banned functions. It not super technical all they did is identify unsafe functions that are hard or impossible to use safely like strcpy, sprintf, and scanf to name a few, and forbid their use. They even developed “safe” versions of the functions that do proper bounds checking and such like strcpy_s. This would have helped prevent the current QuickTime snafu since it was just a simple stack overflow using bcopy incorrectly. This isn't secret Redmond mojo, its just common sense. If it hurts to stick your hand in a fire, don't do it. If programmers can't use functions safely, take away the functions.
Something else Microsoft does that I really think is useful revolves around fixing vulnerabilities. So when they get a vuln report they don’t just fix that problem but also audit the surrounding code and look for additional vulnerabilities. So this RTSP bug is interesting. You may remember MOAB #1, a RTSP buffer overflow in the rtsp address. The current vuln is in an overly long content field. The problems are not directly related but they sure are neighbors. In fact I find it hard to believe you could fix MOAB #1 and not grep the source tree for other potentially bad function use.
Enough about Microsoft, they still have a long way to go. For instance trying to get a security patch for a Windows Mobile device is like trying to land a UFO in a glass of water. That is right UFOs and Windows Mobile security patches both do not exist. I am a big fan of the iPhone because you just plug it in and it will automatically check for updates.
"Vastly" is debatable. The structure is there, Apple just needs to implement it properly. Many of the items Ptacek points out are user-correctible. Apple could be just a dot release away from fixing them if it wanted to.
I stand by the “vastly” statement. You see Apple’s problem in security is not the technology. OSX has a great pedigree with its FreeBSD ties and all these problems previously mentioned are fixable. The problem I see with OS is Apple. Unless I am mistaken the Apple Security team if 4-5 people, or at least it was last year at this time. That is like having one police officer patrol New York City, its ridiculous. You can tell they are understaffed by looking at the patch cycles. An interesting thing to note is that when Microsoft releases patches for their desktop Oses I’ll write PoC samples to see if they could affect Windows Mobile. Why is this important and what does it have to do with patch cycles? OSX ships with a lot of open source software and they occasionally have flaws. Take Samba for instance. Apple shipped Security Update 2007-07 on July 31st (the day before the Blackhat Briefings started) that fixed a number of Samba flaws. The problem is that the Samba project announced the fixes for these flaws in May. That gave resourceful attackers a 3-month window to wreck havoc. The moral of this story is that hackers can take advantage of an understaffed development team just as much as a buffer overflow. I have a list of all open source software that ships with OSX and I pay close attention to any security advisories regarding them. You never know when something innocent can lead to a root compromise.
To continue the Apple Engineer problem sometimes bugs will reappear. Doesn't this look familiar (from the ISC handlers diary). Sure it may be the Japanese version of the software but overly long content type fields are a known problem, why not add a QA test case for simple stuff like that? Or even better, fuzz applications before shipping them.
Apple needs to take security seriously. They need a CSO and they need to stop believing their own press. Take the iPhone, the update features aside I think it has been an abysmal failure in terms of security as exploit after exploit is discovered and released. I think that the iPhone saga illustrates the point that as more people get their hands on OSX the problems will continue to grow.
And that’s all I have to say about that.
