Month of Apple Bugs Debuts in January

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."

Some thoughts and considerations

Brian Krebs seems to have some kind of fascination with "proving" that Mac OS X is "insecure" while simultaneously accusing Apple of using strong-arm tactics to try to silence critics. (Note: going after people for leaking confidential information is not the same as a situation in which people are making security issues known.)

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:Some thoughts and considerations

(I'm not a mac fanboy, but I play one on slashdot)

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.

Re:Some thoughts and considerations

I don't oppose making the bugs public at all. But I do think this needs to be done in a fair manner.

Specifically:

1. Bugs should be in Mac OS X 10.4 (or possibly 10.3).
   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.
2. All bugs should be reported to Apple via Radar.
   Posting without giving Apple advance notice is fine, but forcing Apple to deal with potentially thousands of reports from readers isn't.
3. The web and Radar report should both include steps to reproduce.
   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).

Re:Some thoughts and considerations

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.

Re:Some thoughts and considerations

It would be, if ever Apple actually fixed bugs. The oldest bugs I have in their bug tracking system marked as 'open' are from 2004. The latest one relates to the implementation of NSMutableArray's -sortUsingSelector: method. This is given the name of a compare method and sorts the objects in the array by calling it on pairs of objects. I took some code that used this and worked on PowerPC and compiled it for Intel. After calling this method, the results were incorrectly sorted. Calling it again, they were in a different, still unsorted, order.

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.

Re:Some thoughts and considerations

Can you think of any possible reason why...

You have a memory smasher on Intel that either behaves differently or correctly on PPC.

That's the one that jumps first to mind...

Re:Some thoughts and considerations

This has nothing to do with whether or not holes will be maliciously exploited by some; of course they will be.

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.

Of course?

This has nothing to do with whether or not holes will be maliciously exploited by some; of course they will be.

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.

Re:Some thoughts and considerations

That's insane. No software product, no matter how well intentioned the developers, will ever be completely absent of bugs come release-time. Obviously, defensive code practices and other techniques can reduce the number of bugs generated, and a well-designed architecture can minimize the impacts of bugs that *do* leak through, but no product will ever be perfect.

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).

Re:Some thoughts and considerations

Except that, thus far, OSX has proven itself to be far less bug-ridden, out of the box, than any MS product. If, in five years, Apple has proven to be as unreliable as MS, you can bet people will be complaining just as loudly about them.

Impossible

This can't possibly be true.

OS X is inherently secure. There is no possible way 31 separate security holes could exist; Darth Jobs saw to it personally.

A month of Apple bugs...

A week of Apple games.

Hmm...

[...]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.

This sort of thing seems like a win-win, it's like legal extortion. Either you publish your findings and get lots of attention (sell ads on your site, gain notoriety, etc) or get paid hush money by a big corporation.

Too bad MS doesn't seem to care that much about their rep, or Vista could be a goldmine!

In response to these great efforts

I will be posting his credit card numbers at a rate of one a day. I am curious to see how he responds and if he is able to patch his wallet for each.

It is not up to this schmuck to prioritize Apples develoment tasks. If something he publishs goes wild and affects my company, he will find himself in litigation.

 

Only 7?

[blockquote]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.[/blockquote]

A few years ago, I worked for a corporation to transfer their database into Oracle. Having worked on the project for nine months, I can't possibly see how anybody could have limited themselves to just 7 bugs.

But it seems the summary is surmising the researcher was paid off... I doubt Apple would succumb to such blackmail. If they can find 31 real problems in OS X, then good! Let's tighten things up!

But if it's more "proof of concept viruses" for the mac, then I'll call FUD FUD FUD.

Irresponsible

I'm all in favor of taking Apple to task for failing to fix a bunch of bugs, but releasing detailed information to the public without notifying the vendor first is simply irresponsible. The only reason it's being done this way is shameless self-promotion: if Apple fixed all the bugs in advance, then they'd have nothing left to show for their month of Apple bugs, so people wouldn't freak out about it.

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

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?

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

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

Re:Hint to Apple PR: you can make hay from this

That just escalates this guy's standing and position in the 'newsy' community. Why would you want to build his fame and fortune for him? You pander to his fancies of being a security guru and he will hold you hostage with a 'security review' every time he needs a PR boost.

Ignore this guy and keep doing things the way they've been done. It has been responsive and working.

Test of a common theory!

Hey! This is a unique (and for this mac user, kind of worrisome) oppourtunity to test the MS theory that realeasing this kind of information causes a prolifieration of exploits and only serve to teach people what kind of holes to look through.

If there is a sudden spike in viri and back end hacks on macs, then we'll know. The question is, will the community care either way - if it turns out that this kind of activity rapidly accelerates the spread of black-hat script idiots, will there be reprecussions, or will we fall in along the common mantra that "obsucrity is not protection" (though most snipers would disagree).

-GiH

Also by this author...

Month of Homeland Security Vulnerabilities!
The places where terrorists could to the absolute most damage if they were to strike within the next few hours!

A benefit to the Mac community, surely?

At the moment, MacOS X Hints has a couple of bugs as its first two articles. One is a flaw in Text Editor, the other a possible data loss in iWeb. A month of Apple bugs, to me, means at least 30 bugs found and fixed. Apple has a proven track record when it comes to security updates, and the Software Update function works extremely well to roll out updates with an awe-inspiring ease.

I'd like to say I'm confident they won't find thirty bugs, but that's unlikely. The important thing to focus on, however, is that a bug discovered is a bug that can be sorted. In actual fact, the 'Report bug' options in Safari and a number of other applications shows just how seriously Apple takes this. Bring it on...

Hmm, January 2007...

Isn't something else happening in the OS world... near the end of the month, maybe?

I disapprove

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).

Unethical

Not allowing Apple or any other software developer the opportunity to protect its users from a security exploit and then posting instructions on a public website that allow someone to commit a criminal act is at a minimum unethical and may even open this character up to a lawsuit if anyone is seriously hurt financially or otherwise (remember hospitals, cancer researchers etc use computers). This behaviour shows another agenda beyond helping vendors (well perhaps helping one in particular).

Why don't software companies offer bounties?

Why don't large software companies offer bounties to find their security flaws and disclose them in private before they become a problem? I know security companies do this sometimes, as well as underground organizations to find 0-day exploits, so why aren't the software companies themselves getting into this game? I would think that it would motivate programmers at the company in question to tighten up their code, especially if the bounty cash cuts into their results sharing.

bugs != insecure all the time

Just wanted to point out that a bug doesn't mean any OS is insecure. It could be that a pixel is green where it should be blue... And sometimes one man's "bug" is another's "by design".

Prior Notification

If they give the company a months notice to fix the issues then publishing them afterwards would be incentive for Apple to fix bugs there were made aware about, but failed to fix. Publishing before notifying Apple, sounds like just wanting free bragging rights.

Month of Apple Bugs

To be followed by the Decade of Microsoft Bugs. Welcome, Vista...

Irresposible behavior for security professionals

There are channels and processes for dealing with security issues. Official channels and processes. Failure to use these show the clear lack of professionalism on the security workers' behalf. I would never ever work with these people or anyone who associates themselves with these practices or endorses them (including the company that may employ them). I simply wouldn't ever trust them to be either professional, knowledgeable or to actually work for me.

And I do control a rather large security related budget at a fortune 100 company. They will never get a slice of my security budget...

Month of OpenBSD bugs

Me, I'm waiting for him to do a month of OpenBSD bugs...

stipulated to be true

We can accept the following as a given:

• every system has bugs
• Some bugs will result in the creation of security issues
• Bugs that do not result in the creation of security issues or other user problems will be ignored
• If an exploit does not exist in the wild, the developer will claim a fix for the bug can be deferred
• if a developer is secretly altered of a bug, the developer will claim the fix can be deferred because the bug is secret
• If a white hat hacker has found a bug, then someone else probably has as well
• Just because a exploit is not known, does not mean that it does not exist and just waiting for release
• Hackers that release bug lists are just looking for attention and friends

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.

why not EndNote?

its only an application but maybe he could do EndNote in February (its the shortest month and he may need the rest of the year for Vista), he could easily find a bug a day in that most despised piece of software (which unfortunately has no substitute), I find one most every day without trying......... of course, if he called customer support to report a bug he would be put on hold for the whole month

The implication against Oracle?

I haven't seen any posting that backs up the implication that Oracle did something to halt the "Week of Oracle Database Bugs". I think it's more likely, as others have said, that the researcher just couldn't meet the goals of that project.

Clearly he had issues, otherwise why ask for help, and why do a week instead of 30 days, as the other projects have been?

Does anyone have anything approaching proof to show that Oracle intimidated or otherwise caused the previous project to halt?

There are bugs in Oracle?

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.

Maybe he just couldn't find enough for a whole week?

Riddled, With Bugs

Q: What's worse than finding a bug in your Apple?

A: Finding half a bug!

fair test?

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.

Is it fair to say you are testing the operating system, and then discuss bugs in say, safari? Do we beat on Word bugs when we are discussing Windows security?

Applications run in userland, a bug in a user application is not likely to compromise the machine nearly as far as a bug in the OS. For the purposes of this January test, I will be discounting anything that is not an actual OS bug. (now if a bug in an app is allowed to escallate into the os through a hole in the OS or a bad design of the os's API, then yes we can beat on that all day long, and should)

Reason

He did offer a reason and it was embedded in the binary background of the letter stating he was closing the site. It stated that Oracle Sued. Should go check the comments in the article for that for a rundown on how to obtain it.

Not just a good idea

An excellent idea.

Just imagine if /. hosted a "Month of /. Bugs".

Wouldn't that be a fun trip into humility?