Just seen this on the BBC website
http://news.bbc.co.uk/1/hi/technology/7071017.stm
Check your firewalls folks
Have a read of this by
Jurgen 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 was enough to destroy our misplaced optimism:
# 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
F:CD:B3 (Apple Computer)
It appears that the ports for the previously discovered system services are still accessible. 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.
Risk
Whether the accessible services currently represent a security risk is hard to judge. The fact that Apple uses versions of open source software in which bugs have already been found and documented by the developers is cause for concern. Apple uses ntpd 4.2.2, the current version is 4.2.4. It is not clear whether any of the bug fixes are relevant in this scenario and if Apple back-ported fixes from more recent versions. The same applies to the Samba package (3.0.25b-apple), of which releases 3.0.25c and 3.0.26a contained numerous bug fixes.
Both system services run as root and do not appear to be supported by Leopard's new sandbox functions. If, therefore, a security problem which can be exploited remotely to inject and execute code is detected, an attacker could gain complete control over the system - with all the consequences this entails, right up to mass distribution via a worm.
Workarounds
At present, in order to block access to system services, users must either disconnect the network cable or fall back on the tried and tested BSD ipfw packet filter. This is still present, but by default is set to permeable - the only active rule lets everything through:
$ sudo ipfw list
65535 allow ip from any to any
Users who have already put together a well-honed set of ipfw rules are well advised to continue to use it under Leopard. However, a tutorial on how to generate such a rule set lies outside the scope of this article.
The verdict
The Mac OS X Leopard firewall failed every test. It is not activated by default and, even when activated, it does not behave as expected. Network connections to non-authorised services can still be established and even under the most restrictive setting, "Block all incoming connections," it allows access to system services from the internet. Although the problems and peculiarities described here are not security vulnerabilities in the sense that they can be exploited to break into a Mac, Apple would be well advised to sort them out pronto.
Apple is showing here a casual attitude with regard to security questions which strongly recalls that of Microsoft four years ago. Back then Microsoft was supplying Windows XP with a firewall, which was, however, deactivated by default and was sometimes again deactivated when updates were installed. It was also the case that system services representing potential access points for malware were accessible via the internet interface by default. Despite years of warnings from security experts, the predominant attitude was that security must not get in the way of the great new networking functions.
Then along came worms such as Lovsan/Blaster and Sasser, which rapidly infected millions of Windows computers via security vulnerabilities in system services, causing millions worth of damage. Even today, an unpatched Windows system with no active firewall will be infected within a matter of minutes. However, Microsoft has since learnt its lesson -- a serviceable firewall, activated by default, has been included since Service Pack 2. With the standard configuration, no services are accessible from the internet on a Windows system. (ju) Jürgen Schmidt
haha
