Apple documents Leopard firewall functionality and holes

On its Mac OS X 10.5: About the Application Firewall page, Apple now documents in greater detail than before the functionality and weaknesses of its much-criticised firewall. Thereby the vendor has indirectly confirmed the results of the functionality tests published by heise Security last week, as well as the analysis of its problems with Skype and World of Warcraft. Some of the information contained in the document was already available in the help files and in developer documentation.

Apple emphasises that the new firewall no longer makes decisions based on the properties of individual packets (source and target addresses and ports), but instead filters the network activities of programs. Technically this means it is not a packet filter in the TCP/IP stack but is instead hooks a part of the Mac OS X networking API. Although the original lower level ipfw packet filter firewall is still in operation, Mac OS X no longer offers a front end for controlling it. Only the "stealth mode" in the advanced settings still uses ipfw to suppress status reports via ICMP.

The new firewall recognises applications by means of digital signatures. If a rule is required for an unsigned program, the operating system generates one on the fly. This ad-hoc code signing modifies the program file on the hard drive. This means that programs like Skype or WoW which test their own integrity may subsequently have problems due to a modified checksum. A problem which Apple fails to mention are programs in interpreted languages such as Java or Perl. Here, the user can only define rules which relate to the runtime environment itself, and therefore to all Java or Perl programs.

Apple now also documents that programs bypass the firewall. Even when "Block all incoming connections" is active, the firewall still allows connections which are "important to the operation" of the computer. It is interesting what Apple defines as "important" services. Apart from the service discovery protocol Bonjour (mDNSResponder) this classification also includes any programs running at root level: for example the time server which is activated by default and is always accessible - even when the Mac is directly connected to the Internet.

As previously discovered by heise Security using the netcat network tool, the setting "Set access for specific services and applications" still allows programs signed by a trusted Certification Authority to communicate with the net through the firewall, even if they don't appear in the exceptions list. Which CAs exactly are trusted and thus if everybody can create these signatures is still unclear.

Alltogether this confirms the impression created by the initial functionality test. In its current version, this firewall cannot be recommended for practical use. Practical use could, for example, mean that users leave the security zone behind their firewall routers and connect their MacBook directly to the Internet, for example via UMTS. And that is precisely the situation when it is not desirable that any service started at root level by Apple or a third party is reachable, and hence can be attacked, despite block-everything firewall settings.

The aforementioned time server clearly demonstrates Apple's security philosophy. While other desktop systems like Windows or Linux choose the safer path and use client programs which only access trusted time servers to do regular time synchronisation, Apple exposes the system unnecessarily by using a full scale time server which is open to attacks from internet. We feel compelled to ask how Apple can take such an unnecessary risk and be so certain nobody will ever discover a critical security hole in the ntpd open source software? By the way, the time server apparently does not yet use Leopard's new Sandbox nor are additional ntpd security options like chroot or dropping root privileges active.

That a proper "Block all incoming connections" configuration can be run without major restrictions is not only demonstrated by other desktop systems but also by Macs behind firewall routers which are factory set to refuse connection requests from outside. Those Macs, it may be noted, work almost without restrictions regardless.