The Solaris security record

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):

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.

Paul Murphy wrote and published The Unix Guide to Defenestration.
Murphy is a 25-year veteran of the I.T. consulting industry, specializing in Unix and Unix-related
management issues.