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

Comments

Some thoughts and considerations

[daveschroeder]

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

[gravesb]

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. If, however, they are insignificant or extremely contrived (this application can install malware if the user types in the admin password), then won't it really be an admission that the parties involved can't find critical security holes? (Not that they don't exist, its almost impossible to prove a negative in general one, and that one specifically.) It should be good for Apple regardless, in that major holes are id'd and can be fixed, or their security reputation is improved.

Re:Some thoughts and considerations

[Incongruity]

(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

[daveschroeder]

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.

Re:Some thoughts and considerations

[BarryJacobsen]

What if the reason they haven't been fixed is because some asshat is waiting for a publicity stunt to reveal 30 some exploits that have been found instead of giving them the information to fix them NOW. Some how if this was any field other than computers I think people would look at this very differently: I have some information about cancer and can give a formula that almost any scientist could turn into a working cure given a reasonable amount of time, but I'm going to wait a few weeks and then release part of the information every day for a month on my website (don't forget to click the banner ads!).

Re:Some thoughts and considerations

[Abcd1234]

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

[Abcd1234]

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.

Re:Some thoughts and considerations

[Trillan]

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

[TheRaven64]

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

[ceoyoyo]

Your argument has some merit, but the difference between zero wild exploits for OS X an what, 150,000 or something, for Windows would indicate there's something more going on than marketshare.

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 want probably have a lot to do with it.

Re:Some thoughts and considerations

[99BottlesOfBeerInMyF]

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 something). For a consumer grade desktop, it is reasonable for a company to do a level of testing and design that keeps their product reasonably secure in the real world. Normally, this would be a non-issue, since any product that did not meet these criteria would fail in the market, but one monopoly dominates the desktop OS space and is being leveraged into the server space. In this, I don't think anyone can fault Apple as their product is very rarely compromised, as compared to the other offerings in the market. That is the first issue, dealing with bugs not known by the designers, but which perhaps should be.

The other set of bugs are bugs the vendor knows about, but does not fix anyway. Within a company it is hard to say how many of these exist, but I've been told by former employees MS fixes about half of the security bugs that are reported internally. Further, MS has a poor track record fixing bugs that are know publicly as well. Apple has a pretty good track record with public bugs (not perfect, but good) and I don't know about internal bugs.

I much prefer my OS vendor to be proactive, not reactive, to security.

I much prefer my security vendor to be both, in a balanced fashion. It is good to audit code and design securely, but it is also good to react quickly to known, public threats that probably present more risk.

Re:Some thoughts and considerations

[kwerle]

I'm thinking that you're not the only person who sorts arrays using sortUsingSelector on an intel machine.

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

[99BottlesOfBeerInMyF]

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 "too much work" then you've strongly implied that OS X is fundamentally more secure than Windows, since it is basically no work to make a Windows worm. As for the gain, some worms are still written for reasons of prestige, which the first real OS X worm would create a lot of. For financial gain, some recent worms have begun data mining and Macs have lots of valuable financial data, especially as compared to the average Windows box, many of which are pirated installs running in China or something. Finally, worm authors generally try to spread as much as possible and to new platforms. Adding another exploit to the 6 your worm uses on Windows, will hit those same vulnerable Windows boxes for little return compared to adding one that hits OS X. There have been Linux/Windows cross-platform bugs... why not OS X?

It doesn't help that OS X actually uses a real programming language for the OS - this for the most part helps to keep the script kiddies out.

This is one way, some of OS X is more secure, fundamentally, than Windows.

Here is the thing - when and if, OS X gains a reasonable amount of market share, you can be sure that it, and it's users will become a target.

OS X users are a target for worms now, just not an easy one. More people will try to exploit it as it gains market share, but not just for the reason you imply. One of the reasons OS X is not targeted as much is because malware authors have a fairly limited skill set, much of which is very Windows centric. As more malware authors become mac users, more will also target the mac, in addition to the increased number of potential victims and easier propagation.

What I think many people do not realize is that Microsoft is now trying to deal with protecting users from themselves.

This is a very counter-productive attitude for a security person. Blame is irrelevant to good security, only results matter. You can say that an infection is wholly the user's fault for running an untrusted binary. You can just as logically say the OS failed because it did not provide a good mechanism that let a user safely run an untrusted binary. Since running untrusted binaries is a huge part of what users want/need to do, I think it is unreasonable to blame them for doing this, rather I blame the OS for being designed to accommodate the wrong tasks. I'm not sold on Window's solution to this and I think it has some serious design flaws at present, but in general I think this needs to be addressed.

Most of the malware is now propagated by users themselves.

My personal data and all the presentations at security conferences I saw this year fail to support this assertion. Most malware spreads via user interaction, if you're just counting malware variants. If, however, you're looking at infections, most are the result of malware requires no action from the user. These worms spread faster and more widely than malware that relies upon user interaction.

For example the find a "helpful" toolbar that says: "Download this great new toolbar!" the user clicks OK and they are owned. There is NOTHING to prevent this from happening on OS X, except for the fact that no one has bothered, yet.

There are several things on OS X that mitigate this. First, all the holes that let a download auto execute an arbitrary binary have been quickly plugged. Second, when a user runs a binary for the first time, they are made aware that it is a program and warned and given t

Re:Some thoughts and considerations

[99BottlesOfBeerInMyF]

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

[kwerle]

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

[Trillan]

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

[Anonymous Coward]

Yes, I use these methods all of the time on OS X and it works just fine. Google for endian-ordering and test your code some more.

A month of Apple bugs...

[Anonymous Coward]

A week of Apple games.

Irresponsible

[Phroggy]

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

[toby]

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

[Mr. Underbridge]

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

[tonywong]

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.

Also by this author...

[XxtraLarGe]

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?

[xwizbt]

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

[kiltyj]

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

I disapprove

[Sloppy]

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:I disapprove

[MetaKey]

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

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 well being of the computing community.

Actually, in the short term "LMH" is seriously compromising security. Ethical behavior is to open a dialog with the vendor. If the vendor does not participate in the dialog and demonstrate a good-faith effort to fix the reported vulnerabilities then make the vulnerabilities public.

But, of course, that doesn't get you your 15 minutes of fame..

Re:I disapprove

[alphasubzero949]

Maybe Apple has been told about these bugs and has had an opportunity to address them.

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 /Library/InputManagers. If you think that the easy solution is to not run as an admin for day-to-day tasks, you still have to worry about ~/Library/InputManagers. Apple dismissed InputManagers as a "feature." Fortunately, however, there is an easy way to protect yourself:

mkdir /Library/InputManagers chmod 0700 /Library/InputManagers chflags 017 /Library/InputManagers

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 /Library/InputManagers sudo chown 0:0 /Library/InputManagers sudo chmod 0700 /Library/InputManagers sudo chflags 1600017 /Library/InputManagers

Unfortunately, Panther users have to take an extra step as Apple decided to add a sticky bit to /Library in Tiger without applying that security fix to older iterations of OS X. So in order to enjoy the same permission model, Panther users need to run this:

sudo chmod 1775 /Library

That is one example of how users can protect themselves now instead of waiting for Apple to do something (read: most likely never).

Month of Apple Bugs

[wile_e8]

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

stipulated to be true

[fermion]

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.

Re:Test of a common theory!

[uhlume]

Vista's security system at least in the betas could be bypassed by changing an entry in the registry. That's secure?

...And *NIX's security system can be bypassed by chmod -R 666'ing /etc, adding all users to wheel/sudoers, and/or...well, really, any number of ways. That's secure?

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?

Next up though will be the intelligent ans secure file system. A filesystem that deals with users and permissions on it's own. preventing access to files without authorization.

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?

Of course?

[SuperKendall]

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.