1 2 next »

Jürgen Schmidt

Leopard with chinks in its armour

A second look at the Mac OS X Leopard firewall

Apple is using security in general and the new firewall in particular to promote Leopard, the latest version of Mac OS X. However, initial functional testing has already uncovered cause for concern.

The most important task for any firewall is to keep out uninvited guests. In particular, this means sealing off local services to prevent access from potentially hostile networks, such as the internet or wireless networks.

But a quick look at the firewall configuration in the Mac OS X Leopard shows that it is unable to do this. By default it is set to "Allow all incoming connections," i.e. it is deactivated. Worse still, a user who, for security purposes, has previously activated the firewall on his or her Mac will find that, after upgrading to Leopard, the system restarts with the firewall deactivated.

In contrast to, for example, Windows Vista, the Leopard firewall settings fail to distinguish between trusted networks, such as a protected company network, and potentially dangerous wireless networks in airports or even direct internet connections. Leopard initially takes the magnanimous position of trusting all networks equally.

Switched on

The firewall settings are located under System preferences/Security.

So the first step after starting Leopard should be to activate the firewall. The obvious choice to do so is the option to "Set access to specific services and programs", which promises more control over network traffic. Mac OS X automatically enters all shared resources set up by the user, such as "Remote login" for SSH servers, into the list of accessable resources.

However, initial functional testing quickly dispels any feeling of improved security. A service started for testing purposes was able to be addressed from outside without any difficulty. The firewall records this occurrence

Oct 29 11:05:54 Qf98e Firewall[44]: Allow nc listening from 0.0.0.0:1414 uid = 501 proto=6
Oct 29 11:06:04 Qf98e Firewall[44]: Allow nc connecting from 193.99.145.XXX:37200 uid = 0 proto=6

but clearly sees no reason to prevent it. It is conceivable that Apple intends that every process started by the user should be entered into the list of exceptions automatically. This would, however, also apply to a trojan, covertly setting up a backdoor on the system. Only Apple can explain what precisely is going on here.

Sharing generously

Further tests brought to light more inconsistencies. To examine whether any unwanted services are running, a normal Apple user will consult the graphical front end ("System preferences / Sharing"). However, even when nothing is shown as being active in this front end, a number of services which are intended to be remotely accessible run in the background. These can be detected by using, for example, the command line tool lsof:

$ sudo lsof -i udp
COMMAND   PID           USER  NODE NAME
mDNSRespo  37 _mdnsresponder  UDP  *:mdns
ntpd       46           root  UDP  *:ntp
nmbd      685           root  UDP  *:netbios-ns
nmbd      685           root  UDP  *:netbios-dgm
...

The entries include a time server and the NetBIOS name service from the Samba package (the output from the command has been edited for clarity). It is not entirely clear under what circumstances Mac OS X starts which services - the time server, however, was always running in our tests. Right after installation there was even an active Kerberos server on the test system, which, however, was not restarted when the system was rebooted.

Although none of these services were listed in the firewall's exception list, we were able to communicate with them unimpeded. Even on the internet the time server gave us the time on being requested to do so

$ sudo ntpdate 89.53.249.142
29 Oct 11:12:49 ntpdate[25731]: step time server 89.53.249.142 offset -0.776527 sec

and the NetBIOS service also proved happy to supply us with information despite the firewall:

$ nmblookup -U 192.168.69.21 -A 192.168.69.21
Looking up status of 192.168.69.21
    LOCALHOST       <20> -         H <ACTIVE>
    LOCALHOST       <00> -         H <ACTIVE>
    LOCALHOST       <03> -         H <ACTIVE>
    ..__MSBROWSE__. <01> - <GROUP> H <ACTIVE>
    WORKGROUP       <1d> -         H <ACTIVE>
    WORKGROUP       <1e> - <GROUP> H <ACTIVE>
    WORKGROUP       <00> - <GROUP> H <ACTIVE>

Bonjour - also known as MDNS or Zeroconf - plays a special role here. It broadcasts the availability of services such as SSH to the local network. However, without in-depth knowledge of the protocol we were unable to persuade it to reply to incoming packets.

Battening down the hatches

Users who want to raise their security level might choose the option "Block all incoming connections" - in the hope that this really will reject all incoming queries to network services.

The initial tests looked promising. The SSH server activated for testing purposes and the primitive demo backdoor could no longer be accessed from outside. The firewall even blocked access to a test server on a UDP port:

Oct 29 11:26:49 Qf98e Firewall[44]: Deny nc data in from 193.99.145.XXX:28524 uid = 0 proto=17

However, a simple port scan again raised concern:

# nmap -sU  192.168.69.21
PORT     STATE         SERVICE
123/udp  open|filtered ntp
137/udp  open|filtered netbios-ns
138/udp  open|filtered netbios-dgm
631/udp  open|filtered unknown
5353/udp open|filtered zeroconf
MAC Address: 00:17:F2:DF:CD:B3 (Apple Computer)

It appears that the ports for the previously discovered system services are still accessible. And in fact, even with this firewall configuration it was still possible to communicate with the ntpd time server via an internet connection:

$ sudo tcpdump -i ppp0
10:13:06.944735 IP XXX.heise.de.18099 > Qc39a.q.pppool.de.ntp: NTPv4, Client, length 48
10:13:06.945007 IP Qc39a.q.pppool.de.ntp > XXX.heise.de.18099: NTPv4, Server, length 48

Despite the firewall, the name service replies.

If Mac OS X also launches the NetBIOS name server, this too can be accessed irrespective of the firewall settings. The NetBIOS service is, for example, automatically activated in wired local networks.

A number of peculiarities emerged in the course of testing. A newly booted MacBook refused time synchronisation - only to permit it a few moments later for no apparent reason without any changes to the security settings having been made. Further, it is not clear at what point Mac OS X starts which services, or how it decides which of these should be accessible and which should not.

Specifically these results mean that users can't rely on the firewall. Even if users select "Block all incoming connections," potential attackers can continue to communicate with system services such as the time server and possibly with the NetBIOS name server. continue ...

1 2 next »