% fortune -ae paul murphy

The Solaris security record

Last week's blog about Solaris and openBSD drew this response from "cloder"

Factual errors

Paul, you need a fact checker. You *drastically* overstate the security record of Solaris. You wrote: Like any Unix, Solaris has had hundreds of vulnerabilities exposed and fixed, but there have been essentially no external exploits -and those are the kind I'm most concerned about. Are you kidding? Solaris is the third favourite target for hackers (after Windows and Linux) because of the ease of remote exploitation, and the wide number of available published exploit scripts. I can think of at least 20 different remote root exploits for Solaris from the last 5 years off the top of my head. There's sadmind, telnetd, in.rpcd, in.rwalld, several NIS+ remote exploits, etc. etc. In the same period, I can think of only ONE for OpenBSD: the OpenSSH integer overflow remote root exploit (which, incidentally, affected Solaris too). While your obvious ignorance of widely available and easy-to-find security information is not uncommon, I am disappointed that you are confidently passing your assertions on to your readers.

Download all CVEs and Candidates from mitre, and you get 16,615 entries going back to 1999. Of these, 68 mention openBSD and 425 mention Solaris. Not all these, of course, actually apply to Solaris. My favourite, for example, is this one:

CVE-2002-1844

Microsoft Windows Media Player (WMP) 6.3, when installed on Solaris, installs executables with world-writable permissions, which allows local users to delete or modify the executables to gain privileges.

Drop those which don't apply to the operating system or key components and you're left with 268 Solaris vulnerabilities listed. Of those 13 apply to Solaris 10 and something like 217 apply to releases current during the period -i.e. to 7 through 10.

Note that I'm interested here only in the record on SPARC because I'd never use an x86 machine in a sensitive role - but there'll be a future blog pointing out that there have been more exploits, particularly local ones, for Solaris on x86 than for Solaris on SPARC.

One complicating factor arises from the existence of a special category of pseudo remote attacks - ones which do not need a legal account on the target machine but do require authorised access to key machines on the target's local network environment. The NIS/NIS+ and proxy exploits, for example, fall into this category -and so does the least traceable attack: one in which the attacker uses the network card in PCs running Solaris to trigger a network boot from the attacker's host - enabling him to first mount the target disk as root and later reboot locally, leaving no tracks beyond some access time discrepancies.

Setting aside candidates that don't apply to the SPARC/Solaris 10 environment being considered, we have no known exploits -the same as recent OpenBSD releases. Go beyond Solaris 10, however, to look at history and we have perhaps 9 candidates for Solaris seven through nine against one for OpenBSD.

That makes the immediate bottom line pretty clear: "Cloder" was right (and I was wrong), openBSD does have the better record against remote exploits.

The leading openly available repository for Solaris exploits is probably the milw0rm exploit registry. Here's their list of remote exploits for Solaris on SPARC: (They list eight, but I've dropped the three that depend on non OS software):

1. Solaris <= 10 LPD Arbitrary File Delete Exploit (metasploit)
2. Solaris 2.5.1/2.6/7/8 rlogin /bin/login Buffer Overflow Exploit (SPARC)
3. Solaris Sadmind Default Configuration Remote Root Exploit
4. Solaris sadmind Remote Buffer Overflow Exploit
5. BIND 8.2.x (TSIG) Remote Root Stack Overflow Exploit

Of these the first Sadmind exploit is particularly interesting. First the code is written in Perl, which makes it easy to understand and easy to adapt. Secondly, and more importantly, it exposes the fundamental nature of most Solaris exploits, whether local or remote, because all it really does is call a known system function in the intended way to create an unintended effect.

Specifically, the default interface was set up to be open - a hangover from the early RPC days when people assumed that everyone with access could be trusted. Indeed look at all Unix vulnerabilities and RPC related issues accumulate an easy plurality - a consequence, ultimately, of releasing software designed for a trusted collegial environment for use in the so called "real" world.

As I noted in the original blog part of the attraction openBSD has for me in the situation described there derives from the fact that it installs closed -meaning that when the next guy along eventually installs an upgrade, he'll start with a box on which none of the external access methods work and be forced to think about what to turn on. Right now, Solaris 10 doesn't do that: by default it installs and starts up a lot of services, like wbem, that have to be specifically turned off for security.

Since most of the vulnerable stuff from the past falls into that category the only downside to a Solaris decision is that it imposes greater responsibilities on my successor, so I'm not changing the decision - but Cloder was right: the Solaris record against external attacks is significantly worse than openBSD's and I should have checked more carefully.