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."
Re:Irresponsible (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 to prove that it is not. Hell, you could say it is more irresponsible to not release them to the public than to just submit them to be fixed to Apple. If every XP exploit was sent in like that people would think/know XP was the safest thing around... either way those sys admins you spoke of still have a hard job no matter what. So they have to guard against new threats with these going public... what is new there? That is there job, to be on top of this. That is why they read /. and know where to look to see what the bugs actually end up being when released.
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 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...
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: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:Some thoughts and considerations (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 application signing framework for determining trust of applications. Combining these two, you have most of what is needed to build a system that is reasonable secure, by default, for the average user who wants to run random software.
First, asking users for a password should be a very rare thing and always accompanied by specific comments on what the software wants and granular options as to what it is allowed to do. Suppose some user downloads Firefox. It is easy for this program to be signed and check-summed as coming from an official source. Better yet, there is no reason it cannot be verified as from a reputable group from a free certification agency or from Apple themselves. This speaks to the trust level as determined by the second framework I mentioned. On the other hand, some malware might be signed as from a specific Website, but any such software somehow signed as from a specific reputable company would be discovered and the cert revoked very quickly. This places it one or two notches down the trust ladder.
When each of these programs is run, different restrictions are put in place. A signed and certified app like Firefox is given an ACL specified by the app itself, and customizable by the end user. It can open only files it creates without asking and can access the internet and a few services. Or, it is only certified as from a given Website. In which case it can still only access files it creates (limited in total disk used), and it cannot access the internet. When run, the user is informed that it wants access to the internet on ports normally reserved for Webpages and the user is given the choice of letting it access the internet or not or customizing that access. When the malware is run, it to is restricted to accessing only files it created and cannot access the internet. If it wants to send spam the user is given a choice. If it wants to access an address book, the user is given a choice. If it wants to patch the kernel and install a rootkit the user is given a very strongly worded choice along the lines of "The program 'toolbarwhiz' would like complete access to control your computer completely for all time. This behavior is typical of a malicious software. (Stop it from completely controlling my computer for all time)(Let it have complete control of my computer forever)(advanced options).
Such a warning is sufficient to deter most credible software vendors from selling unsigned software that asks for unreasonable permissions. An official software registration/activation service removes another big portion of the motivation for this. Such a system is not trivial to build, but it is within the bounds of what we can currently create. It would stop the vast majority of both worms and trojans and make creating new ones a difficult social engineering challenge. Until we get to a level of security functionality such as I just described, I don't think user education for the masses will work. They need the tools and control first, before a reasonable amount of education will be effective.
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:I disapprove (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
mkdir
and likewise for your home Library folder. If you really want to tighten things down to the point where you need to boot into single user mode, do this instead:
mkdir
Unfortunately, Panther users have to take an extra step as Apple decided to add a sticky bit to
sudo chmod 1775
That is one example of how users can protect themselves now instead of waiting for Apple to do something (read: most likely never).