Month of Apple Bugs Debuts in January 171
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 (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.
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).
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.
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.
Re: (Score:2)
Well, this sort of thing certainly wouldn't stop them from fixing bugs and it'd likely put more pressure on Apple to fix a bug or two, so I don't see how it'll end up worse for users and developers, unless Apple really doesn't care about their code quality, in which case, this'll illustrate it well enough that we'll all hear it loud and clear (assuming serious bugs are discovered in this process).
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: (Score:2)
We couldn't.
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...
Re: (Score:2, Informative)
Re: (Score:2)
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.
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.
Re: (Score:2)
I don't think so at all. It's an indication of the sad state things are in when security holes are accepted as inevitable. If we still have buffer overflows in the year 2006, it's because nobody has really bothered to do what's necessary to eliminate them once and for all. (Switching to a safe language like Cyclone [att.com] would fix all these, for example.) Ditto format string vulnerabi
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).
Re: (Score:2)
Re:Some thoughts and considerations (Score:4, Insightful)
Re: (Score:2)
Re: (Score:2)
Except TeX ; )
Re: (Score:2)
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:2, Insightful)
Re: (Score:2)
Re: (Score:2)
Because none has been written? How many people have bothered to write something for an OS with ~ 4% of the market share when there is a whole 96% out there waiting to be owned, apparently no one. There has been one attempt at a rud
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
Re: (Score:3, Insightful)
Because none has been written? How many people have bothered to write something for an OS with ~ 4% of the market share when there is a whole 96% out there waiting to be owned, apparently no one.
This is an unsupported assertion. Logically, just because there are no propagating worms does not imply that no one has tried and failed to create one.
There has been one attempt at a rudimentary Trojan recently, but OS X goes largely unexploited, and for good reasons - too much work with little gain.
If it is
Re: (Score:2)
All the security in the world isn't going to stop john q jane from authenticating itself and allowing a malicious program to run as root if it doesn't know any better. The only thing that will stop it from taking that action is it fully comprehending the chain of events that led to the request, and the subsequent outcome of approving it. I think many individuals just don't care, or don't understand the implication of such actions.
I will add
Re: (Score:2)
All the security in the world isn't going to stop john q jane from authenticating itself and allowing a malicious program to run as root if it doesn't know any better.
Umm, what? who is john q jane and why are they an "it" and if they are an "it" how can they know anything? Please rephrase this in understandable English.
I think many individuals just don't care, or don't understand the implication of such actions.
Of course they don't. They're trying to accomplish a series of tasks and making the reason
Re: (Score:2)
Incorrect. Only when you click a non-executable file that will open in a previously unused program are you warned. Clicking an executable directly gives no warning.
Also, as the ".app" extension is hidden by default, it is trivial to create an app named along the lines of "HotChick,jpg.app" with a Preview JPEG icon that will
Re: (Score:2)
Re: (Score:2)
Users, windows, linux, unix, bsd, what have you - if they don't know why, or don't care why they are being asked for the password, or are tricked into thinking that they are doing one task while executing another, may supply the root password to a bad program. There has already been a demo of such an exploit where a fak
Re: (Score:3, Interesting)
I'm just making the point that 95% of the people out there just don't know enough to prevent getting pwnd.
I'd argue that systems don't let people easily run untrusted software safely and give them enough information and granularity of control to allow the average user to avoid being compromised. Apple announced some new frameworks in 10.5, and then pulled the references to them from their public facing Web pages. Those frameworks were a Mandatory Access Control framework for applications and an applicat
Re: (Score:2)
No they hadn't and they won't. From the Washington Post [washingtonpost.com]: "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."
Just a publicity stunt.
Re: (Score:2)
With all those caveats what you're really saying is that OS X is more secure than Windows. Because Windows is the only viable alternative for most users as a general purpose desktop OS.
Well duh. More secure than Windows; that's not exactly an achievement.
The problem is that OS X and Windows are both at the bottom of the pile for security. OS X is marginally better than Windows but they
Re: (Score:2)
Sounds like a busy month for you, Dave. (Score:2)
Wow--I don't know how "you" do "it," "Dave." Even your preemptive spin on the month-of-bugs makes my iB
Re: (Score:2)
I, for one, have grown quite tired of Apple and the the MacFanBoi's claims that OS X is perfectly secure.
1. Apple does not, and never has, claimed Mac OS X is "perfectly secure" or anything near "perfectly secure".
2. No reasonable person makes that claim. If some jackass wants to say that Mac OS X is invulnerable, they're exactly that. A jackass.
Its even prevalent on the securityfocus list dedicated to Apple products, where every security concern, malware or exploit is
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.
Re: (Score:2, Interesting)
Sure he may be doing this for self promotion, but what is wrong with using your knowledge to get some recognition? What he gets from this will be worth far more than what he would if he submitted these bugs to be fixed to Apple. Unless Apple is ready to thank he personally for all the bug fixes in a public manner and allow him to post the exploits after they were fixed, then why not?
It is not his public duty to make sure Apple's OS is safe, if anything, it is his
Re: (Score:2)
Re: (Score:2)
First you give the company a head start in fixing the security hole before a well package exploit go public.
But you get you shameless self promition of being "Mr. Uber Geek, I am smarter then you because I have more free time to do these things.".
If the patch isn't released shortly after posing people can take additonal measures to protect their system.
It is like finding a persons (lets call h
Re: (Score:2)
No way. If he discovered ways to bypass a security system, and knowingly gave thieves access to my property, he would be -- ethically for sure, and most likely legally -- a willful accomplice to trespass and any associated crime. Whether he's granting access to my land, my safe, a bank vault, or my computer, it's trespassing and it's a crime he participates in.
I couldn't care less what his beef is with Apple; the fact that he's distributing this information to people who would use it to commit crimes, be
Re: (Score:2)
I once told a friend that if you eat polonium you will die. I suppose that makes me re
Re: (Score:2)
And yet, if a locksmith writes a book that details how a certain brand of lock is not secure, including reproducible instructions given in order to prove he is correct, and then someone uses that book to break into your house, that locksmith will IN NO WAY be liable for your loss.
If he did it with malice aforethought and took pains, like this anonymous jerk, to ensure that the manufacturer is caught with their collective pants down, then yes. This sensationalist "security researcher" is a sadist, sitting back and instilling fear, intentionally enslaving the vendor to work on their product in sequence of his priorities, in some kind of sick race to see if the vendor can fix the problem before the customer, caught in the middle, gets ripped off.
If you publish exploits in any mediu
Re: (Score:2)
Re: (Score:2)
He wants to publish a list of ways your computer can be maliciously affected, and then what? Will he stand back and say "this is it, I'm not responsible for how it's used?"
That's almost a textbook definition of irresponsible - doing something and not taking any blame for the repurcussions.
Yes, it's not directly his fault if a hacker
Re: (Score:2)
Re: (Score:2)
I also wonder though as an aside: here on Slashdot, and I tend to agree with the arguement, there are critques of analysts at 'independent' research firms for not doing their research properly and it therefore impacting upon the public perception (read: stock performance) of the company be analysed.
I have to wonder if there is also an economic downside to this type of research. And sure, Apple is a 'big' company by most measures but the bottom line still effects wether or not peop
Re: (Score:2, Insightful)
Re: (Score:2)
Re: (Score:2)
So yeah, assuming Apple hasn't already found these bugs independently, they are 0-day and previously undisclosed.
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
Memo to Mr Underbridge (Score:2)
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.
security guru? (Score:2)
As others have pointed out, it's pretty difficult to make your OS X system vulnerable. Many home and corporate users are already behind a router. The others can tighten their software firewall and disable unnecessary services.
That leaves the usual attack vectors, Outlook and IE... uh wait... Mail.app and Safari. Even if he has some remote exploit against standard mail client and browser, unless this stunt suddenly changes
Re: (Score:2)
I doubt the guy wants to work with anyone.
As I just quoted in another post:Washington Post [washingtonpost.com]: "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."
I guess his emphasis is on page views and ad revenue. Not making the world of computers a saver place. Hope that doesn't shatter your weltanschauung.
do they need advance notice? (Score:2)
Yeah, I know, I'm hopelessly naïve.
Re: (Score:2)
Re: (Score:2)
He'll be scraping the barrel to find one or two. And either way, I still think it's a PR opportunity for Apple. Or at worst, tuff love!
Re: (Score:2)
Re: (Score:2)
Work with this guy. Simply ensure that each bug identified is fixed ASAP, and issue a press release about it.
It sounds like (especially based on their last such publicity stunt, that "this guy(s)" does not want to be worked with, and just wants maximum drama and exposure for his site. Interesting that one of them doesn't want to be known by name. They don't sound particularly co-operative, especially if they had anything to do with the "wireless security flaws" beat-up.
stunt will probably backfire (Score:2)
Thirty exploits for OS X would be quite a find - and if they have them, let's get them outed; OS X users aren't in as much danger from this as people around here are trying to claim.
Test of a common theory! (Score:2)
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 w
Re: (Score:2)
The fact is that *nix's dealt with mass propagating viruses and auto excuting text formats 20 years ago. They figured out how to limit their spread simply. OS X while not bullet proof or perfect has at least a solid foundation to work with. Windows including Vista has an unstable one at best. Vista's security system at least
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
Re: (Score:2)
On OS X the root user isn't activated that command can't be given. Ubuntu is doing the same thing. Viruses can't spread that way without a lot of manual input by the user.
Re: (Score:2)
Re: (Score:2)
The common mantra is not "obscurity is not protection". The common mantra is "Security through obscurity is really not security." You're repeating a common misunderstanding. If instead you read "Security that relies on obscurity is bad" then you have a better understanding of the criticism of security through obscurity.
In other words, obscurity may help, but it should not be the primary feature of
Re: (Score:2)
I appreciate that argument for releasing data on security breaches under the theory that "the bad guys know this, the good guys don't" if it should turn out that they are instead cheap classes on compromising common system architecture, I would feel the need to wonder what steps could be taken (by law makers) to discourage them.
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!
Re: (Score:2)
Re: (Score:2)
Actually, if the terrorists are REALLY clever, they'll take down all the jewelry stores and florist shops and stands on Christmas Eve. The damage done by the women to men who saved their gift shopping for the last minute should shut the country down for weeks (taking down the florist shops prevents effective apologies, of course).
A benefit to the Mac community, surely? (Score:2, Interesting)
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 th
Re: (Score:2)
Re: (Score:2)
I've read articles in the past that mentioned Apple was often slower than Microsoft at releasing critical updates.
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
Re: (Score:2, Interesting)
Like InputManagers? Oompa-Loompa, Inqtana.B, and more recently, 'iAdWare' all used InputManagers in order to execute as admins easily have read/write access to
Re: (Score:2)
Because if they just gave out all the info now, in a couple weeks Apple will have issued a patch for most/all of them, which would spoil the effect for Vista's launch. If they release them one at a time, Apple wont be abl
Re: (Score:2)
strike
Why don't software companies offer bounties? (Score:2)
Re: (Score:2)
Re: (Score:2)
Prior Notification (Score:2)
Month of Apple Bugs (Score:2, Funny)
Month of OpenBSD bugs (Score:2)
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.
The implication against Oracle? (Score:2)
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? (Score:2)
Maybe he just couldn't find enough for a whole week?
Riddled, With Bugs (Score:2)
A: Finding half a bug!
Re: (Score:2)
Re: (Score:2)
-Kurt
Re: (Score:2)
I guess it just proves that Mac fanbois have no sense of humor.
(FWIW, I always saw Jobs as Palpatine in SW:TPM. Benevolent on the face, manipulative and nasty in the background. His use of Woz and little percolations on Jobs's ego makes me see this)
Re: (Score:2)
Darth Torvalds
Darth Bush
Darth Jobs
Darth Stallman
Darth Blair
Darth Bin Laden
It's okay to find meta-humor amusing - i.e., the fact that Apple fanboys don't find it funny -- but posting to elicit that kind of response is trolling by definition.
Now, personally, I wouldn't waste mod points modding it down anyway, but I would not m2 Unfair someone who did. My only point is this: You're not being nearly as
Re: (Score:2)
Re: (Score:2)