Sure, it's not a screaming emergency, but that's no excuse for Apple to leave it unaddressed this long:
The vulnerability was addressed in FreeBSD and NetBSD last [sic] last summer.It's just plain stupid on Apple's part to not address something that opens them to this kind of FUD article. The facts are correct as stated: The vuln was known long ago, other BSDs corrected it long ago (including FreeBSD, the basis for OS-X), and Apple should have done so, period. Screaming high priority? No. But it's very foolish from a "PR" point of view to stand around with one's pants around one's ankles like this.
> Three weeks from a major Apple announcement... it's open FUD SEASON
True, and more will follow. Nevertheless, Apple is in the wrong on this one, and for no apparent reason other than foolishness.
What is the absolute WORST CASE senario if this remains un-fixed in OS X? The vulnerability is in a nonexecutable memory location - thus it cannot do anything at all. As someone else posted - put it on the list for “some day” just fore the principal of it. But I see no grand hurry.
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.