Mitre.org's CVE registery contains about 425 Solaris vulnerability reports of which about two thirds have some relation to Sun supported software. Look at those carefully and you see mention of 21 apparently distinct exploits.
Here, for example, is the main entry for several lp and lpset related vulnerability claims dating back at least to 1997:
Name: CVE-2000-0317
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2000-0317
Phase: Proposed (20000518)
Category: SF
Reference: BUGTRAQ:20000424 Solaris 7 x86 lpset exploit.
Reference: URL:http://archives.neohapsis.com/archives/bugtraq/2000-04/0192.html
Reference: URL:http://archives.neohapsis.com/archives/bugtraq/2000-04/0236.html
Reference: BUGTRAQ:20000427 Re: Solaris/SPARC 2.7 lpset exploit (well not likely !)
Reference: URL:http://marc.theaimsgroup.com/?l=bugtraq&m=95729763119559&w=2
Reference: SUNBUG:4334568
Reference: BID:1138
Reference: URL:http://www.securityfocus.com/bid/1138
Buffer overflow in Solaris 7 lpset allows local users to gain root
privileges via a long -r option.
Current Votes:
ACCEPT(3) Levy, Baker, Cole
MODIFY(1) Frech
NOOP(3) Christey, LeBlanc, Wall
RECAST(1) Dik
Voter Comments:
Dik> there's a lot of confusion in this one.
These point to buffer overflows:
Reference: BUGTRAQ:20000424 Solaris 7 x86 lpset exploit.
Reference: URL:http://archives.neohapsis.com/archives/bugtraq/2000-04/0192.html
Reference: URL:http://archives.neohapsis.com/archives/bugtraq/2000-04/0236.html
But these point to dlopen() in libprint that doesnt' check pathnames:
Reference: BUGTRAQ:20000427 Re: Solaris/SPARC 2.7 lpset exploit (well not likely !)
Reference: URL:http://marc.theaimsgroup.com/?l=bugtraq&m=95729763119559&w=2
Reference: SUNBUG:4334568
And this is a bufferoverflow again:
Reference: BID:1138
Reference: URL:http://www.securityfocus.com/bid/1138
Frech> XF:solaris-lpset-bo
Christey> ADDREF SUN:00195? Need to check with Casper.
Follow each such claim through the maze of references and redirections and in 17 out of the 21 cases you'll end up with something like this exchange:
[From: TRG]Setuid proggie /usr/bin/lp has an easily exploitable buffer overflow. This exploit is for Solaris 7 x86 version, no sparc exploit is available to my knowledge.
/*
*
* solaris 2.7 /usr/bin/lp local exploit, i386.
*
* discovered by DiGiT.
* try offset 150-250 if sploit fails
*
* greets: #!ADM, #!security.is, #hax, duke
*
* DiGiT - teddilinux.is
*
*/
#include
#include
...[From: LLR]
Hi,
I got this exploit working on multiple Solaris (2.5.1, 2.6 & 7), Sparc version.
It is similar, but based on lpset command instead of lp, but root privileges gained in a second.
Will mail it soon.
This one is unusual in that there is a followup to that bit about the SPARC exploit being in the mail:
Cheers,
As promised, here is the sparc version code for these exploits.
Works fine with lpset, did not try on lp.Trusted me, it works fine..
Just change shellcode to :
char sparc_shellcode[] =
"\x82\x10\x20\x17\x90\x20\x60\x17\x92\x22\x40\x09\x91\xd0\x20\x08"
"\x2d\x0b\xd8\x9a\xac\x15\xa1\x6e\x2f\x0b\xdc\xda\x90\x0b\x80\x0e"
"\x92\x03\xa0\x08\x94\x1a\x80\x0a\x9c\x03\xa0\x10\xec\x3b\xbf\xf0"
"\xdc\x23\xbf\xf8\xc0\x23\xbf\xfc\x82\x10\x20\x3b\x91\xd0\x20\x08"
"\x90\x1b\xc0\x0f\x82\x10\x20\x01\x91\xd0\x20\x08";
and get_esp to:
u_long get_esp() { asm("mov %sp, %i0"); }
This should be enough to have the sparc version
But, else complete Sparc version (lpset variant):
#include
#include
#define BSIZE 18001
...
The SPARC version he attaches, compiles and runs: but needs the older 32bit kernel from an unpatched early release to work -and even on those simply setting noexec_user_stack = 1 (the default in the 64bit kernel for the US2 and higher) in /etc/system defangs the thing.
There are two obvious morals to this kind of story: first, the SPARC exploit requires the victim to wear one red sock, his unlucky tie, be left handed, and drive a Miata, but a working x86 exploit is attached.
Second, and more importantly, this particular exchange took place in 2000, when x86 Solaris had essentially a zero market share and Sun was considering dropping the technology -but the bad guys still found it worth attacking.
And that leads to an important observation: it's not market share that attracts the attacks. So why do it? perhaps because the SPARC version is hard, but the x86 architecture makes it easy to score points against Solaris?
There's a much less obvious issue here too: in the process of trying to map CVE's to exploits I discovered that very nearly everybody in the security business quotes very nearly everybody else -meaning that there's usually little or no independent research or verification behind many of their pronouncements. As a result I can review both LLR and TRG's attached code, review Sun's acknowledgement of the vulnerability and the fix, and still not end up knowing for sure whether the claimed SPARC version was a real exploit workable against real systems. There appear, for example, to have been no victims.
I imagine it's different for people who work in this industry full time, but I've read through nearly a thousand CVEs, clicked until my fingers hurt, read until my eyes blured, and I still don't have an exploit count I can believe in. At best I'm guessing there have been a bit less than one hundred local exploits (authorization upgraders like the one above, file disruptors, or service deniers) for Solaris on SPARC; something like 14 remote RPC psuedo-exploits (illegitimate uses of legitimate facilities) of the kind defeated by basic system hardening; and somewhere from four to seven genuine remote attacks likely to have been effective against a properly secured web accessible machine at the time they were released.
Two things, however, are clear: first x86 exploits significantly outnumber SPARC exploits. Thus I found no examples of SPARC exploits that didn't have x86 variants and at least 17 remote exploits for x86 for which there's no compelling reason to believe a generally workable SPARC version ever existed.
Second, it's clear that the security industry as a whole presents a very distorted picture of security threats. Any threat vaguely affecting any Unix variant is immediately embraced: it's applicability broaded to as many Unix variants as remotely possible, and any exploit claim accorded instant and total credibility.
So what does all this add up to? In part it means that the more I look at this stuff, the less sure I get about anything, but right now I'd guess that the real ratio of vulnerabilities to exploits (including local ones) for x86 is roughly one to one, while the same ratio for SPARC (and probably PPC) is at least sixty to one or better.
Since a vulnerability without an exploit doesn't matter to users, these ratios mean first that SPARC (and probably PPC) vulnerabiities will probably continue to be technical issues with little or no relevance to users.
Secondly, and more importantly, the Solaris x86 experience suggests that CPU architecture is a much more important factor than market share in determining whether or not exploits are developed. As a result it's reasonable to predict that Apple's decision to abandon PPC for x86 means that the MacTel community will become as easily, and therefore as frequently, victimized as Wintel users have been.