Apple Responds to MOAB

frdmfghtr writes "Apple has released what appears to be the first security update as a result of the "Month of Apple Bugs." While the Apple site doesn't explicitly say that the fix was a result of the MOAB, it does point to a sample Quicktime file that triggers the overflow flaw (well, sort of...it says the file is there but doesn't provide any links)."

Comments

ummm

[Kyro]

from the linked apple release: " A QTL file that triggers this issue has been published on the Month of Apple Bugs web site (MOAB-01-01-2007). This update addresses the issue by performing additional validation of RTSP URLs."

is that not explicit enough??

Re:ummm

[DLG]

Yeah, it is hard to accuse Apple of dodging the project by explicitly highlighting their 'contribution'. I wonder what the author wanted to see.

"Oh Noez, W3 WUZ PWNED by the MO@B Kr3w!!!!"

Really pretty respectful to simply describe the bug, and describe the exploit that is specifically focussed on that bug, pointing the the source of it.

I think that MOAB did focus attention on some real issues although they had to stretch out some issues to multiple days (several DMG file structure errors which essentially were DOS at worst (a corrupt file shouldn't cause crashes it is true, but that can be one day worth of bugs since the fix is essentially 'validate file more effectively before loading it')

As far as the questions about things like diskutil restoring permissions on files that have lost their SUID bits due to being modified, thats a solid issue, although diskutil is run by administrative account from what I recall, and really points back to the question of how do you avoid having someone with an account on a machine they have in their home or office from getting root access, and then not doing stupid things to their machine. Basicly the same can be said about any system that allows someone root access. There is no OS that can stop SU from fraking things up as far as I know.

Anyway, I think the real truth is that there are no great showstoppers. Omniweb closed their security flaw the day it was released (and wondered why they couldn't have been contacted prior to the publicity. Any argument that 'Apple ignores bug reports' sort of goes to hell when talking about third party software issued). Even worse was day two's focus on VLC a project that has less relevance on Apple's OS than it does in the Linux world. I think they should have focused on things Apple needed to fix, rather than things that break on Apples, just like they break everywhere, without Apple having much to do with it at all, nor any real influence on the developers. I mean technically you could put any Window security issue into the Apple MOAB since Windows apps run on Macs these days. Is that helpful? Not really.

So I would say that Apple has shown a willingness to respond to a bug report, I have not really seen them creating negative press against the MOAB folks, and there hasn't really been a showstopper that was strong enough to get mainstream press.

Response

[99BottlesOfBeerInMyF]

So what is the proper response to the MOAB people? They are revealing real bugs, some of which could be exploitable. Ignoring them leads to decreased security. At the same time they have behaved very irresponsibly with regard to those bugs they have found, not notifying the vendor and providing time to fix before publication, nor following the route of immediate disclosure, the MOAB people seem to think it is all right to sit on bugs they find until the most convenient time for them to gain publicity. Worse, they intentionally space out the publication of the bugs, making a Dev/QA cycle to fix them have to wait till the end or commit to missing some. As such they have maximized the time of exposure for these bugs which encourages worms by giving malware authors as much time as possible.

Obviously increasing the security of end users is not the top priority. Accurately informing the public does not also seem to be their top concern since they named their project "Month of Apple Bugs" while many of the bugs they've announced are in third-part code (some of it cross-platform) that has nothing to do with Apple. It seems to me all they care about is publicity and sensationalizing themselves in the hope that they can capitalize upon it. Looking at them in that light, it makes sense to spread out the announcement of these bugs and not inform vendors beforehand because it increases the likelihood that people will be compromised, giving them the opportunity to go to news outlets ands say, "see we told you this might happen."

Given all of the above, what can be done? I'd certainly never want to work with people who eschew responsible disclosure and are interested only in themselves, nor would I trust them. But any press is good press, and most people are not security people and won't even understand what it is these people are doing, they'll just know they got press for security research. Is there any way the security or computing community can discourage this crap in the future and make it clear that irresponsible behavior like this is unacceptable?

Re:Response

[99BottlesOfBeerInMyF]

And I think you are way off here saying they are only looking out for themselves.

It is the only reason for this method of disclosure I can think of.

Have you every attempted to do a disclosure with Apple? It's nearly impossible.

What? They have a bug reporting form on their Website. You don't even have to give them any info on who you are. I've submitted bugs that were fixed in short order, although none were security issues. My coworker a few offices down submitted a local escalation security bug though and it was fixed a few weeks later and he was given credit in the the security update. How is that "nearly impossible?"

These 30 odd bugs they are going to release would take apple YEARS to fix if this disclosure method was not taken.

That's just bullshit. If they found the bugs this month and handed them all to the respective vendors then announced the results at the end of next month all the vendors would fix them before the announcement.

I'm sure both of these researchers are Apple users or such a project wouldn't have taken place.

At least one of these "researchers" has performed the month of bugs thing on other vendors, one of which was cancelled when he was paid off, as I understand it.

It's my belief that they are sick of Apple's antics and simply want results.

If they followed the schedule I listed above, and Apple did not fix them within that one month dev/QA time these guys could scream bloody murder and I'd be right behind them. They'd be following responsible industry practices and Apple would be in the wrong. I'm firmly convinced they did not do this because they were pretty sure Apple would fix the bugs and they would get only minor press once, instead of ongoing sensationalist press.

Also, before you go to far in defending these guys, you do know they are now accused of illegally exploiting one of their bugs against users before announcing it, right?

Re:Response

[99BottlesOfBeerInMyF]

Spoken like a true Mac apologist. How dare anybody manipulate any information, timing, or accuracy to make my computer company look bad! Welcome to the world that Microsoft lives in, here's your initiation T-shirt.

Who cares about making Apple look bad. I'm concerned about the very real security implications of these actions. They're putting people at risk in order to get press and ignoring the established practices of the industry. You can argue for delayed disclosure based upon vendor response. You can argue for immediate disclosure. Now do tell me the argument for not informing the vendor and not informing the public until a specific day. It doesn't matter what vendor they are doing this to, it is still unethical.

Where is this outrage when an unpatched Windows bug is announced?

There are valid reasons for announcing an unpatched bug in some situation and I fully support that. In some cases there are even valid reasons for announcing a bug to the public immediately without disclosing it to the vendor first. That said, this is neither of those cases. There is no security justification for immediate disclosure in this case. And, they aren't disclosing immediately, but are delaying disclosure.

Admittedly, flaws in 3rd party software don't really seem to have any business in the MOAB list, but of the 23 issues they've reported so far I believe only 3 have been for 3rd party apps.

That would be 6, not 3... or approaching 1/3 of them.

The fact is that yes, there is a "more responsible" way that vulnerabilities should be handled by the MOAB team. However, Apple could do a better job as well.

I think that is understating the case. They're accused of actually using the bugs to exploit users before announcing the bugs. That goes way beyond "less responsible" and enters the realm of "probably criminal." As for disclosure times, When you're dealing with a vendor that provides no feedback and has a history of slow bug fixes and you think the vulnerability might be being exploited in the wild and there is a work around, immediate public disclosure makes sense and increases overall security. When you're dealing with a bug in OmniWeb that is almost certainly not being exploited, it makes no sense. These guys provide immediate feedback and turn around security related bugs in hours. Yet the MOAB project not only did not give them hours, they never bothered to inform them of the bug at all and they had to learn of it from someone who read the MOAB and reported it to them from there. That is indefensible.

The whitewashing job Apple has done demanded (to some people) a highly publicized "retaliation" to prove that, indeed, Apple's feces doesn't smell like roses after all.

Whitewashing job? Do elaborate. How is Apple covering up security problems or misinforming people?

This is the message that just doesn't seem to get across to Macintosh users, and until they not only get the idea that their OS isn't 100% secure, and that they need to take precautions just like Windows (and Linux) users then people like this MOAB team will continue seeking publicity more than seeking to "responsibly" get vulnerabilities reported and resolved.

Umm, but Mac users to date haven't had to take any security measures to have a negligible possibility of malware infection. That could change in future and Apple should be proactive about keeping it that way, but you can always spend more effort on security. I'd like Apple to do more, but so far they have been "good enough" and I haven't seen them misinforming anyone. Some of their Ads may oversimplify, but that is a good thing since most people don't want complex messages about computers security. "Get a mac and you're safer than if you have Windows" is about as complex as the average consumer can handle and remember.

Re:Response

[99BottlesOfBeerInMyF]

I was more troubled by the way they treated Omniweb...

Even more troubling is the hubbub surrounding their Colloquy vulnerability, mentioned in this article. They are accused of actually using the exploit on a public IRC channel before releasing the vulnerability and publishing a log of that hack in the announcement. I don't know if it is true, but given their behavior with the rest of this project they're slipping more and more towards the blackhat end of the spectrum.

Re:So...Is The QT Flaw the Only Notable Bug?

[solevita]

Also: is Steve Jobs technically a bug or a feature?

I'm told he's the irreplaceable core of Apple inc, so I guess he's neither a bug nor a feature; he's Apple's Internet Explorer.

I posted this elsewhere too...

[jpellino]

This fix is in line with the typical timing and attention given Apple security updates - relatively quick and competent.

This pretty much busts MOAB's claims of Apple's ignorance and/or hostility at bug reports.

Apple has been doing better than most, fixing 99.9% of their problems through their established channels without MOAB's brand of nonsense. Count all the bugs fixed thru the normal dev bug report process. Count all those fixed by MOAB's. Compare.

IIRC nearly a third of their "Apple Bugs" are 3rd party problems to begin with.

MOAB are still flaming Apple Inc., Apple users, and anyone else who critiques their methods, and it's gotten personal and insulting. They come out swinging their fists at the Apple community, then cry foul because someone hits back.

If Apple users make you cry, go kick your tires.
You want the world to believe that you're a responsible developer that anyone will listen to or hire, prove it in daylight.

Lots of comment...

[shawnce]

I am see several comments from folks stating that they are surprise that Apple is taking steps to patch issues ("taking it seriously", etc.). I find that a little strange comment given that Apple is actually rather good about addressing vulnerabilities that others report to them and give them credit (if they reported it to Apple). Granted Apple's general no comment policy until investigated and patched can be a little annoying if you report an issue and would like to know more but that policy doesn't mean that Apple doesn't take security reports seriously.

Just review all of the attribution Apple has given for the many vulnerabilities they have addressed over the years. For example look at the security release announcements for 2006 (mailing list archive).

As a side note a few MOAB issues are centered on group admin writable locations that can be used to take over the system is you have local access (possibly via a remote exploit). It may take Apple a little while to address this type of issue given the possibility of permission changes causing Apple and 3rd party software (installers most likely) to fail for customers. Luckily a few new security related feature will debut in Mac OS X 10.5 that will make this type of attack harder to pull off (us 3rd party developers should adopt them ASAP).

A brief listing...

CoreGraphics
CVE-ID: CVE-2006-1444
Available for: Mac OS X v10.4.6, Mac OS X Server v10.4.6
Impact: Characters entered into a secure text field can be read
by other applications in the same window session
Description: Quartz Event Services provides applications with
the ability to observe and alter low-level user input events.
Normally, applications cannot intercept events when secure event
input is enabled. However, if "Enable access for assistive
devices" is on, Quartz Event Services can be used to intercept
events even when secure event input is enabled. This update
addresses the issue by filtering events when secure event input
is enabled. This issue does not affect systems prior to Mac OS X
v10.4. Credit to Damien Bobillot for reporting this issue

Keychain
CVE-ID: CVE-2006-1446
Available for: Mac OS X v10.3.9, Mac OS X Server v10.3.9, Mac OS
X v10.4.6, Mac OS X Server v10.4.6
Impact: An application may be able to use Keychain items when
the Keychain is locked
Description: When a Keychain is locked, it is not possible for
applications to access the Keychain items it contains without
first requesting that the Keychain be unlocked. However, an
application that has obtained a reference to a Keychain item
prior to the Keychain being locked may, in certain
circumstances, be able to continue using that Keychain item
regardless of whether the Keychain is locked or unlocked. This
update addresses the issue by rejecting requests to use Keychain
items when the Keychain is locked. Credit to Tobias Hahn of HU
Berlin for reporting this issue.

GDB
CVE-ID: CVE-2006-4146
Available for: Mac OS X v10.4 and later
Impact: Opening a maliciously-crafted DWARF binary with GDB may
lead to arbitrary code execution
Description: GDB, the GNU Debugger, is susceptible to multiple
vulnerabilities that may lead to arbitrary code execution when
loading maliciously-crafted DWARF binaries. This update
addresses the issues by performing additional validation while
handling DWARF binaries. Credit to Will Drewry and Tavis Ormandy
of the Google Security Team for reporting this issue.

etc.