I'm not even certain it's a "vulnerability" in OS X. The example Proof of Concept code is apparently non-working on OS X, as some people are reporting that the POC, when run on OS X.6.2, returns:
Program received signal EXC_BAD_ACCESS, Could not access memory.which would be consistent with the non-execute nature of the memory locations of the data stacks and heaps . . . perhaps it's a total non-issue.
Reason: KERN_PROTECTION_FAILURE at address:
If it can't do any damage, IS it a vulnerability? If it can't work, can it be a vulnerability? Look at the actual wording of the article (the stress is mine):
"The vulnerability is a potential buffer overflow error arising from the use of the strtod function Mac OS X's underlying Unix code."
"Potential" is a big word in this context... and with Apple using non-execute memory locations for the data that is at risk for this overflow, it seems to obviate this potential risk. It also seems to me from reading the description of the PoC, that they are assuming that is a threat to OS X because it is in the underlying UNIX code.
It also may have been fixed on one of the Apple patches. Apple mentioned in one of the recent security updated that they had repaired several inconsequential buffer overflows in old code. perhaps this is one of the unnamed burrer overflows.=, and that Security Associates is making the assumption that just because Apple did not address it by name as a "serious" vulnerability, because Apple did not consider it as one, it's still open.
I think you guys are missing the point.
The strtod() function has a bug -- a software mistake, a flaw, something done wrong -- which allows buffer overrun. Lots of the original Unix library functions had these, because they didn't check for boundary conditions or limit input length or something similar. Those functions, as classic and historic as they are, are insecure, and are not to be used in a secure operating system.
How hard is this to understand? It's a known bug, with a known fix that is not difficult. And there's a working applicable example of the fix in FreeBSD.
The fact that the no-exec feature keeps the bug from being overtly dangerous DOES NOT EXCUSE LEAVING IT THERE UNFIXED. It's stuff like this that justifies the anti-Apple slurs about Apple being arrogant. As an Apple customer, I find that very unfortunate.
Many years ago, a Microsoft spokesman was asked to justify the fact that Windows and Office were shipped with known bugs that could have been fixed, but weren't. The answer was, "Our customers don't want perfection. They want a product that is 'good enough' to use. So that's our criterion. And we think that our software, bugs and all, is good enough for you."
I find Microsoft's haughty attitude offensive, and I am sorry to see that Apple has apparently adopted it.
As I said twice above, the problem is NOT technical. The problem is that Apple paints a big "KICK ME" on their own butt by leaving something like this unaddressed, knowing that anti-Apple tech writers salivate over the possibility of composing headlines like "Mac OS X Vulnerability Goes Unpatched For Months". As above, it's just stupid PR.