Slashdot Log In
Month of Apple Bugs Debuts in January
Posted by
Zonk
on Tue Dec 19, 2006 01:14 PM
from the sure-to-raise-some-eyebrows dept.
from the sure-to-raise-some-eyebrows dept.
An anonymous reader writes "A pair of security researchers has picked January 2007 as the Month of Apple Bugs, a project in which each passing day will feature a previously undocumented security hole in Apple's OS X operating system or in Apple applications that run on top of it. According to a post over at The Washington Post's Security Fix blog, the project is being put together by researchers Kevin Finisterre and the guy who ran November's Month of Kernel Bugs project." From the post: "It should be interesting to see whether Apple does anything to try and scuttle this pending project. In November, a researcher who focuses most of his attention on bugs in database giant Oracle's software announced his intention to launch a "Week of Oracle Database Bugs" project during the first week of December. The researcher abruptly canceled the project shortly after the initial announcement, without offering any explanation."
Related Stories
[+]
"Month of Kernel Bugs" Project Head Interviewed 42 comments
An anonymous reader writes "November has been labelled the 'Month of Kernel Bugs' in security circles. The Month of Kernel Bugs began on November 1, with the publication of a vulnerability in Apple's AirPort drivers. SecuriTeam blogs did an interview with LMH, who hosts the project."
[+]
Apple: Month of Apple Bugs - First Bug Unveiled 240 comments
ens0niq writes "The first bug (a Quicktime rtsp URL Handler Stack-based Buffer Overflow) of the Month of Apple Bugs has been unveiled — as previously promised — by LMH and Kevin Finisterre. From the FAQ: 'This initiative aims to serve as an effort to improve Mac OS X, uncovering and finding security flaws in different Apple software and third-party applications designed for this operating system. A positive side-effect, probably, will be a more concerned (security-wise) user-base and better practices from the management side of Apple.'"
[+]
How Apple Orchestrated Attack On Researchers 389 comments
An anonymous reader sends us to George Ou's blog on ZDNet for a tale of how Apple's PR director reportedly orchestrated a smear campaign against security researchers David Maynor and Jon Ellch last summer. Ou has been sitting on this story ever since and is only now at liberty to tell it. He posits that the Month of Apple Bugs was a direct result of Apple's bad behavior in the Maynor-Ellch affair. From the blog: "Apple continued to claim that there were no vulnerabilities in Mac OS X but came a month later and patched their Wireless Drivers (presumably for vulnerabilities that didn't actually exist). Apple patched these 'non-existent vulnerabilities' but then refused to give any credit to David Maynor and Jon Ellch. Since Apple was going to take research, not give proper attribution, and smear security researchers, the security research community responded to Apple's behavior with the MoAB (Month of Apple Bugs) and released a flood of zero-day exploits without giving Apple any notification. The end result is that Apple was forced to patch 62 vulnerabilities in just the first three months of 2007 including last week's megapatch of 45 vulnerabilities."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Some thoughts and considerations (Score:5, Insightful)
Every reasonable person on the planet already knows, and has known, that every OS has bugs, vulnerabilities, and security issues, and Mac OS X is no exception. The simple, undeniable truth is that for a variety of reasons, including marketshare and the security architecture of the OS, Mac OS X is a far more secure general purpose desktop operating system for most users than any viable alternative. There is almost zero malware of any kind "in the wild", no malware with vectors for mass propagation, and little with ANY kind of propagation capability whatsoever. And contrary to popular opinion among some, Apple does indeed respond to, and fix, security vulnerabilities, including crediting the discoverer(s) when said person or entity provides Apple with enough information to verify the issue. It has continuously and consistently improved on this front, mostly as a result of working with people in the enterprise and academic communities (e.g., Apple University Executive Forum and MacEnterprise.org). There is always room for improvement, but we have seen Apple make marked progress in disclosing, accurately describing, and fixing vulnerabilities in Mac OS X. As with most commercial vendors, Apple does not comment on security issues before they are fixed. So don't expect Apple to make public statements and explanations of any kind until after a particular vulnerability is addressed.
What should be "interesting" to see isn't whether or not Apple "does anything" to "scuttle" the project; it will be whether Apple has previously had any chance to respond to any of the issues that will be disclosed. If not, this little project doesn't prove anything at all, other than that every operating system, Mac OS X included, has bugs. (Duh?) What's important is the general security architecture, practical security state-of-affairs on the platform, and how the vendor responds to issues. I'll be far more interested to see how and when Apple responds to the issues raised, and if it properly "triages" the issues and handles them accordingly (on this note, predict that people will complain Apple is taking "too long" to fix some of the issues, when in reality it is devoting programming and testing and QA resources to the issues in the order of importance and impact).
Re: (Score:3, Insightful)
Re:Some thoughts and considerations (Score:5, Insightful)
I also think the quality of the bugs will be interesting. If all 30 bugs are show stoppers, then there are some serious underlying issues that should be addressed.
And I totally agree. If there are bugs, better to have them out there and then fixed than it is to have them be obscure pieces of knowledge that a motivated few will use for their gain.
In the end, a month of OS X bugspotting can only be a good thing, IMHO.
Parent
Re:Some thoughts and considerations (Score:5, Insightful)
I don't oppose making the bugs public at all. But I do think this needs to be done in a fair manner.
Specifically:
Pre-release software is not a fair target. It's under NDA, and is bound to have a bunch of issues. Apple has a system in place for dealing with 10.5 issues.
Posting without giving Apple advance notice is fine, but forcing Apple to deal with potentially thousands of reports from readers isn't.
This really falls under the category of "duh." A bug report that can't be reproduced is simply not worth much (although it isn't entirely worthless).
Parent
Re:Some thoughts and considerations (Score:5, Interesting)
The three points I addressed were pre-release, radar, and repro steps.
Now I consider bugs from private betas covered by NDAs to be forbidden fruit, and that's true of Microsoft as well. However, public betas are fair game. So it depends on the nature of the release, both for Microsoft and Apple..
Although it's possible there's another system somewhere, the only system I'm aware of for reporting bugs to Microsoft requires me to pay them. They may, at their discretion, return the money. I'm not risking my money to help Microsoft, so I don't expect anyone else to. And since Microsoft doesn't have a public and free bug reporting system, the repro steps would have to be public only at first. I don't like public only. Ideally, vendors should be notified first; simultaneously is the minimum. But by plugging their ears and requiring a credit card number, they're digging their own grave here.
I should say, by the way, that I don't especially like bugs being publicly disclosed quickly. It wouldn't be the way I'd handle it. But I don't think people who do it should be tarred and feathered. Maybe that wasn't clear.
Parent
Re:Some thoughts and considerations (Score:5, Interesting)
I thought it must be my code, so I added a load of debugging output to my -compare: method. I found that the it was giving the correct result, and enough comparisons were performed to be able to create a sorted array. The final results, however, did not reflect this; if the comparisons said a is before b, and b is before c, the resulting array would often contain a c b.
I was going to just copy the GNUstep implementation of this method into a category and use this in my application, but when I looked at it I noticed that theirs called -sortUsingFunction:context: where the context was a the selector and the function was one that just invoked the method. I wondered if Cocoa did this too, so I tried using -sortUsingFunction:context: with a function that just called my -compare: method. And then it worked. It seems that someone wrote some 'clever' optimisations for Intel in the -sortUsingSelector: method, and broke it completely.
Parent
Re: (Score:3, Funny)
I'm also thinking that they probably haven't done anything with that particular code in the past 8 years.
I am thinking that it is a problem with your code.
Re:Some thoughts and considerations (Score:4, Insightful)
You have a memory smasher on Intel that either behaves differently or correctly on PPC.
That's the one that jumps first to mind...
Parent
Re:Some thoughts and considerations (Score:5, Informative)
What matters most is how Apple responds to issues once it knows about them, whether it discovers them internally, is privately informed, or finds out via a project like this.
You can't fix a bug you don't know about, and saying Apple should somehow magically know about them all itself is disingenuous. All software will have bugs, and people other than the vendor will always discover some of them. Some of these bugs will be able to be used as avenues for exploit.
The only question is whether, as a responsible security researcher, you give the vendor a chance to respond before disclosing, or not. This has zero to with what other malicious people will do.
I understand you're probably one of those people who doesn't think there is any value at all in informing the vendor and giving them an opportunity to fix an issue before widely disclosing it, so this discussion isn't likely to get anywhere.
Parent
Of course? (Score:4, Insightful)
Of course? Why would that be?
Some holes disclosed previously have, for example, included flaws in the OS X SSH daemon. You might think that would make a great target to exploit, except that it doesn't ship enabled by default - so the universe of computers you are going to be able to reach with a remote attack is exceedingly small. Thus, even though there's an exploit you probably would not see one for that hole.
Similarly other exploits previously disclosed have been in areas you can only reach by penetrating the OS in the first place, or gaining admin access. Again this initial effort to reach that position makes writing exploits more trouble than it's worth.
So generically, you cannot say that every hole automatically leads to a malicious exploit. If that were true, there actually would be viruses and malware for OS X today.
Parent
Re:Some thoughts and considerations (Score:4, Interesting)
The "Windoze Haters" feel the way they do because, time and again, Microsoft has demonstrated that they produce software which is not only very buggy (certainly more so than their competators), but faulty by it's very design (eg, wiring IE into the OS, which made it a perfect vector for infection). Worse yet, when they release fixes, they are just as likely to introduce *new* bugs as fix the old ones, demonstrating a significant lack of competance (not to mention further calling into question the underlying architecture).
Parent
Re:Some thoughts and considerations (Score:4, Insightful)
Parent
Re: (Score:3, Insightful)
So it's okay if (and I'm not suggesting this is the case) you design something with severe holes all over the place, as long as you fix them when it's brought to your attention? You might want to tell all the "Windoze Haters" here. Apparently this is not acceptable.
You've presented a false dichotomy. It is unreasonable for a developer to create insecure bug ridden software, with no testing, unless it is unlikely for other reasons that that software will be compromised (only running on an internal net or
Re: (Score:3, Insightful)
Sure, OS X gets shielded because it's not as common, but total protection? I think being built on UNIX, already having security features that MS is building into Vista, separating user accounts and root, all incoming ports closed by default and not having your web browser and mail client allowed to do whatever they wa
A month of Apple bugs... (Score:3, Funny)
Irresponsible (Score:5, Insightful)
In short, their goal isn't really to get these bugs fixed ASAP; their goal is to spread fear and panic. If the bugs get fixed eventually, that's just icing on the cake. The problem with this is that it could cause some real problems for Mac network admins out there, many of whom don't have a lot of extra time to deal with unpatched security holes. If it was just a matter of "sticking it to Apple", that would be one thing, but this will affect a lot of innocent victims.
Yes, I'm a Mac user. No, that isn't why I feel this way; Microsoft should get advance notice too.
Hint to Apple PR: you can make hay from this (Score:4, Insightful)
Work with this guy. Simply ensure that each bug identified is fixed ASAP, and issue a press release about it. This lets you capture and keep the high ground by showing that you care more about security and quality than the competition does. Up for it?
Just remember, where the big bad guys see "little people to be silenced," others see "opportunity."
Re:Hint to Apple PR: you can make hay from this (Score:5, Funny)
Memo to Apple PR: Work with this guy. Simply ensure that each bug identified is fixed ASAP, and issue a press release about it. This lets you capture and keep the high ground by showing that you care more about security and quality than the competition does. Up for it?
Memo to toby: We don't negotiate with terrorists.
--Steve
Parent
Re:Hint to Apple PR: you can make hay from this (Score:5, Insightful)
Ignore this guy and keep doing things the way they've been done. It has been responsive and working.
Parent
Also by this author... (Score:5, Funny)
The places where terrorists could to the absolute most damage if they were to strike within the next few hours!
Hmm, January 2007... (Score:3, Insightful)
I disapprove (Score:5, Insightful)
I have to admit I sometimes waffle on my opinion regarding disclosing to vendors first, versus disclosing to the whole world simultaneously. Both approaches have some advantage.
This approach does not.
If the goal of disclosing to the whole world is to give users a chance to defend themselves (since it is assume that black hats may already know about these holes, and may already be expoiting them) then why delay until January?! And why dole out the information one bug, one day, at a time?
By delaying, you gain the disadvantage of vendor-only disclosure: today's users aren't getting the information to at least try to protect themselves from exploits that are possible right now.
Best-case, you also may get the advantage of vendor-only disclosure. Maybe Apple has been told about these bugs and has had an opportunity to address them. But the article doesn't say that. We just don't know. So that's a best case, and the worst case is that we'll get the disadvantage of simultaneous public disclosure: the script kiddies get to start exploiting the bugs right away, while the users have to wait for a fix from a big clumsy vendor. And that's not counting the intentional delay, where people might be exploiting the bug between now and the disclosure.
This is a bad idea, no matter which camp you're in (exception: black hats).
Re: (Score:3, Insightful)
Actually, yes, we do know.
FTFA: "As with the kernel bugs project, Apple will be given no advance notice with the Month of Apple bugs, LMH said in an interview conducted over instant message."
It's a childish and self centered move on the part of "LMH" to NOT inform the vendor. Apparently, he is more concerned about puffing himself up than with security or the wel
stipulated to be true (Score:3, Insightful)
Given all of these varied assumption, there is no simple answer to the reporting of bugs. There is really no reason to keep the bugs secret, as that does a disservice to the customers and allows the manufacturer to postpone a fix. If the issue is serious, then it will get out anyway, and the sooner the fix the better. By making the bug public, the developer can openly discuss the issue and justify the action or inaction.
In the end the only shitty thing to do is sit on a bunch of bugs and then release then in mass. This of course is going to overwhelm the developer, and expose a bunch of issues that cannot be quickly be fixed. It is not only an attack on the developer, but an attack on the innocent users. I have no problem with hackers releasing bugs as they are found, but building up an arsenal is something that only black hats would do.
As far as if a particular OS is secure, this probably has more do with the quality of code rather than error rate. Even quality code will have errors. The difference is that quality code is written in such a way that side effects are minimized by clearly defined interfaces and domains of data. This leads to code that can be easily fixed without the problem of a change effecting many other unrelated systems. Ever since we were told that MS Windows can not function with IE or WMP, and it took 5 years to generate an upgrade, we are all very suspicious about the code quality of MS Windows.
Re: (Score:3, Insightful)
Oh wait, yeah, it is.
It goes without saying that any administrator knowledgeable enough to change system settings (particularly those which aren't exposed for easy access) has the capability and the potential to change them to some