Folks,

So now that the Month of Apple Bugs project is over, how many of them were really ones we should worry about?

http://projects.info-pull.com/moab/

To jump ahead to the punch line, only one bug is problematic, and even that one requires that the user take a positive action. It can't just happen to an otherwise idle machine, or be triggered just by looking at an e-mail or web page. Even that last one can be patched by a sysadmin so that it can be neutralized even before Apple releases an official patch.

Bugs by the Numbers

So, let's look at what constitute worrisome bugs, i.e. ones that would give potential root-level access, in order of increasing severity:

1. A bug in a third-party application - 4 (#'s 2, 7, 16, and 19)

With a few very rare exceptions, these are the hardest for an attacker to exploit since there is no guarantee that any particular machine will have the application installed. Most of the time a user can easily switch to an alternative application with little or no loss of functionality.

2. A bug in a third-party system extension - 3 (#'s 8, 18, and 27)

These are things that install kernel extensions and root-level daemons. Easier to exploit since they work at a lower level than user applications, but again many if not most users will not have these installed and most users can switch away to a different extension or daemon.

3. A bug that requires action by an admin user - 14 (#'s 1, 3, 4, 5, 6, 9, 10, 11, 15, 20, 23, 24, 26, and 28)

These are vulnerabilities that require an admin user who is logged in to the Mac to take some positive action like clicking on a link or running an application. Running as a standard user makes these a non-issue.

4. A bug that requires local access but no action by an admin user - 0

These are vulnerabilities that require that an admin user be logged in, but not take deliberate action to trigger the bug. An example would be a bug in WebKit where simply viewing an HTML-formatted e-mail triggers the vulnerability. Many Outlook worms on Windows spread this way.

5. A bug that requires local access by a standard user - 3 (#'s 12, 21, and 22)

Like category 3, but running as a standard user does not protect against them.

6. A bug that requires local access but no action by a standard user - 0

Like category 4, but running as a standard user does not protect against them.

7. A bug that requires network access via a protocol that is off by default - 2 (#'s 14 and 17)

These are more dangerous, in that the machine only has to be on with the sharing protocol turned on. No one has to be logged in. However, the network protocols associated with this category of vulnerabilities are turned off by default.

8. A bug that requires network access via a protocol that is on by default - 0

Same as category 7, but the network protocols are on by default.

Comments on the Bugs

Bug 21 - System Preferences writeconfig Local Privilege Escalation Vulnerability - The preference pane's setuid helper, writeconfig, makes use of a shell script which lacks of PATH sanitization, allowing users to execute arbitrary binaries under root privileges.

This one is a case of really bad programming practice by Apple. Anything executing as root should not run a shell script as a sub-process in the first place.

Bugs 12, 13, 25, 29, 30 - These are denial of service bugs that don't lead to code execution. While annoying and potentially worrisome as a part of a more sophisticated attack, none of them are by themselves serious security threats.

Bug 31 - This one has not been released, so it's hard to say what it's worth. It is presented as a kernel vulnerability, potentially the most severe category of threat. In most cases the courteous thing to do is to give the vendor a chance to release a patch for the bug before disclosing it. On the other hand, the MoAB people have not been shy about disclosing other potentially serious bugs, so why should they delay on this one?

Conclusions

I would say that Apple came off pretty well in this month of bugs. Seven out of 30 are not even Apple's problem, leaving only 23. Five more are denial of service and not code execution, leaving only 18. Of the 18, none can be exploited without some sort of positive user action — opening a file, clicking a link, or turning on a service. Running as a standard user eliminates 14 of the bugs, leaving only four, or even two if you don't have the vulnerable services turned on.

Does this mean that you can ignore Mac security? Of course not. However, it shows that a Mac faces a relatively low security threat level. First, if you've followed my advice you are running as standard user and have all unnecessary services turned off. This means that you are only open to three of the bugs. Second, since the Mac has so many fewer vulnerabilities, the *propagation rate* of a piece of malware is vastly slowed, giving sysadmins and Apple time to put up defenses.

Here is one case where a biological analogy is actually useful — it's the difference between the spread of a disease in a population that is partially vaccinated vs. one that is unvaccinated. Even though only some of the population is immune, that is enough to slow the spread of the disease so that public health authorities can get ahead of the curve and stop the epidemic easily.

FYI, Apple has patched bug #1 in Security Update 2007-001 and #'s 9, 20, 22, and 29 in Security Update 2007-002, leaving only one (#21) that is truly troublesome. If you follow the procedure in http://projects.info-pull.com/moab/MOAB-21-01-2007.html then you can neutralize this last bug.


--Paul