Slashdot Mirror
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."
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).
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.
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.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
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."
you had me at #!
Isn't something else happening in the OS world... near the end of the month, maybe?
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).
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
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.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
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 something stupid. So long as the defaults are sane for people who wouldn't know from a registry entry or a group file, who cares?
Now you're just stringing words together for fun without regard to meaning. Do you have even the foggiest notion of how filesystems are actually implemented? What are you trying to describe, and how is it different from EXT3 or NTFS or any even remotely modern kernel-level filesystem?
SIERRA TANGO FOXTROT UNIFORM
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley