cop-01.txt

` January 3, 1999  
  
  
Corruptio Optimi Pessima  
"corruption of the best is worst of all"  
  
  
  
Vulnerability: Automountd  
Operating System: SUN Solaris  
Versions affected: 2.5, 2.5.1, 2.6, 2.7 (X86 and SPARC architectures)  
  
  
  
[ Rant -------------------------------------------------------------- ----  
  
You pay for this? Why is it vendors can't get the hint? Network users  
demand secure software, not poor attempts at patching longstanding holes  
in the current revisions. Sun was warned about this bug years ago, and  
over time all they could come up with is a single broken patch that reminds  
us of the first Microsoft fix for the port 139 OOB attack. Why does it  
take vendors like Sun over three MONTHS to patch this kind of hole?  
They claim that it takes that long because of the level of testing they  
must put the software through. Right. So not only do they supply a   
broken patch, they test it for three months and never notice it is still  
vulnerable, then release it to their paying customers.  
  
You pay for this? How many security vendors knew about this and said  
nothing? Why did CERT never report this? Why have hackers been passing  
these exploits around for two years? Why didn't the ueber-spies of the  
ICSA get their hands on this and report it? Why didn't Sun's own   
"security analysis team" of 70 people find this bug (or any others)?  
Could it be job security? We think so.  
  
---- ------------------------------------------------------------------- ]  
  
  
[ Details ----------------------------------------------------------- ----  
  
Back in 1995, a vulnerability was discovered and a new world of buggy   
software born. This particular bug, would be conceived when Sun   
Microsystems made the foolish decision to ship Solaris 2.5 to customers.  
  
Since then, it has been a downhill roller coaster for the boys and girls   
at SUN. Now, not only is 2.5 affected, but 2.5.1 stock, 2.5.1 patched,   
2.6 and 2.7 are all affected as well.  
  
This bug is particularly important, because it shows the incompetence  
of Sun Microsystems. Not only do they sit on patching bugs for months  
at a time, they cant even patch bugs right!  
  
When exploit code for the local automountd problem was leaked a few  
YEARS ago, SUN developed a patch and labeled it #104654-05. However,  
intrestingly enough, even after the patch was released, this bug  
could still be exploited quite trivially.  
  
What SUN decided todo, was remove the 'popen' call and put in its place  
an 'execve' call. Absolutely brilliant. Did they forget that  
the variable holding the program and arguments to be execued could  
still be set by issuing a AUTOFS_MOUNT call to automountd? Or,  
is this a case of job security by one of Sun's engineers? We certainly  
feel it is the latter.  
  
Either way, not only is this bug local, but it is remote too!  
And, not only is it remote, but it is started by default as well!  
  
Yes, thats right boys and girls, you can now execute any program  
you like on any default installation of SUN remotely! When exploiting  
this vulnerability, be sure to send SUN your warmest compliments.  
  
Now, getting back to the bug at hand, a few things have to be established  
before this can be exploited.  
  
First of all, to remotely exploit this bug, it becomes two-pronged.  
Meaning, we are now going to introduce another remote bug in the  
SUN Solaris operating system that when combined with the previous,  
create a lethal combination.  
  
This new bug, located in rpc.statd which is also started by default  
(imagine that!), allows for remote packets to be bounced to the local  
Operating System.  
  
Looking back at the details of automountd, we remember that it cannot  
accept packets on UDP or TCP protocols. But, it can accept packets on  
the TLI protocol, which rpc.statd happens to forward to, allowing us   
to remotely execute commands by sending our packets to rpc.statd.  
  
So, with all this in mind, if we send two RPC packets to rpc.statd on   
Solaris 2.5, 2.5.1 stock, 2.5.1 patched, 2.6, or 2.7, with the SM_MON  
and SM_NOTIFY commands, rpc.statd will happily forward the packet  
on to the local operating system's automountd daemon.  
  
Variables we will have to setup will be the following:  
  
struct mon monr;  
struct status stat;  
  
memset(&monr, 0, sizeof(struct mon));  
  
monr.mon_id.my_id.my_name = cache;  
monr.mon_id.my_id.my_prog = (unsigned long)AUTOFS_PROG;  
monr.mon_id.my_id.my_proc = (unsigned long)AUTOFS_MOUNT;  
  
mon_id.my_id.my_name will be our cache, which we will be using to  
tell rpc.statd where to forward the packets to.  
  
The cache of the remote system can be found by establishing a connection  
to port 23, or port 21 of the system. The cache will usually appear inside  
parentheseis, and will be the hostname of the machine.  
  
Another example of obtaining the cache, would be to lookup the ip address  
of the machine and use the hostname that comes back.  
  
For example, for pathetic.sun.com, you could try 'pathetic' or  
'pathetic.sun.com', and it will be a pretty safe bet that you will   
pick the correct hostname.  
  
mon_id.my_id.my_prog will be the variable AUTOFS_PROG telling rpc.statd  
which RPC service to connect to.  
  
mon_id.my_id.my_proc will be the variable AUTOFS_MOUNT telling rpc.statd  
to tell automountd that we want a AUTOFS_MOUNT request.  
  
Further variables to setup:  
  
monr.mon_id.my_id.my_vers = 1; /* For Solaris 2.5, 2.5.1 */  
or  
monr.mon_id.my_id.my_vers = 2; /* For Solaris 2.6, and 2.7 */  
  
monr.mon_id.mon_name = command;  
stat.mon_name = command;  
  
monr.mon_id.mon_name and stat.mon_name will both contain the program  
to execute on the remote system.  
  
Now, with those variables setup, we can send off our RPC packets  
to the remote system.  
  
However, to complicate things more, we must modify our tekneeq of  
exploiting this bug, for it to succeed on 2.6 and 2.7.  
  
Because SUN implements a new function called SMHASH in rpc.statd on  
Solaris 2.6 and 2.7, we will now have to involve DNS spoofing  
to acomplish executing our command.  
  
Because of the way SMHASH works and the way RPC arguments are encoded,  
our command is what SMHASH attempts to lookup in its address tables  
once rpc.statd receives our packet.  
  
If SMHASH cannot detect if our command is a valid address, it will  
not forward the packet. However, if we DNS spoof our command off  
the Primary and Secondary nameservers of the remote system, SMHASH  
will return true for finding the command as an address and our  
packet will be forwarded.  
  
If you wish to test this bug without DNS spoofing, you can also  
modify the /etc/hosts file on the Solaris system and put in the  
command you want to execute (without arguments) as a hostname  
with an ip address, and it will accomplish the same affect.  
  
For the actual exploit code to do this, I will let the reader go on  
to the next section to find it.  
  
Examples:  
  
If pathetic.sun.com were a Solaris 2.7 machine with pathetic  
as its hostname, and a vulnerable Primary name server,  
an exploit attempt would look like this:  
  
Execute commands to spoof reboot off Primary NS here  
./amountdexp pathetic.sun.com pathetic reboot 1  
  
If pathetic.sun.com were a Solaris 2.5.1 machine with pathetic  
as its hostname, an exploit attempt would look like this:  
  
./amountdexp pathetic.sun.com pathetic reboot 0  
  
---- ------------------------------------------------------------------- ]  
  
  
[ Exploit ---- ------------------------------------------------------ ----  
  
Exploit code for this vulnerability can be easily obtained from the  
following URL: http://www.attrition.org/hosted/cop/index.html  
  
---- ------------------------------------------------------------------- ]  
  
-----------------------------------------------------------------------------  
-----------------------------------------------------------------------------  
  
Date: Mon, 4 Jan 1999 23:23:48 -0600  
From: Scott <[email protected]>  
To: [email protected]  
Subject: Re: SUN almost has a clue! (automountd)  
  
This is in response to Mr. Corruptio's post of:  
  
Corruptio Optimi Pessima  
"corruption of the best is worst of all"  
  
the title of which seems to imply that Sun is "on the take" to wreck it's own  
OS. Or I suppose it could just be something cute sounding that he used his PC  
mouse to drag out of someone's signature :)  
  
I realize that the primary focus of this list is serious security (or the lack  
thereof), but I'm getting a little winded by the unnecessary commentary that  
accompanies some of these reports. I'm not fixing to launch into an attack of  
my own, instead I'd like to try a somewhat more constructive approach and  
attempt to actually answer some of the questions raised below.  
  
First:  
  
[] "Why is it vendors can't get the hint? Network  
[] users demand secure software, not poor attempts at patching  
[] long-standing holes in the current revisions."  
  
Not exactly true. The primary Solaris market is large corporations, database  
operations, ISP's, etc. These are very sophisticated, and multifaceted users  
with a whole range of concerns that compete with (or oppose) security concerns  
for priority. Ease of use and interoperability are two huge concerns at present  
- and both are generally regarded as somewhat of a contradiction to strong  
security. All of these issues compete with each other constantly. Certainly  
just after a break-in that caused some terrible problem - yes, at that moment in  
time security is a top concern. Next week, when the newest version of some  
compiler fails at some task...well that issue takes center stage. The REAL  
question that needs to be asked is - is a user willing to pay MORE for the OS to  
be more secure? GENERALLY speaking...the overwhelming answer is no. Don't  
scream and jump up and down just yet...keep reading.  
  
[]Why does it take vendors like Sun over  
[]three MONTHS to patch this kind of hole?  
[]  
[]They claim that it takes that long because of the level of testing  
[]they must put the software through.  
[]  
  
  
I've been dealing with Sun for 12 years. I've never heard anyone make this  
claim. And in truth, as we all know, it doesn't take 3 months to test a patch.  
I have actually asked Sun this very question. The answer I got was much more  
believable.  
  
It took 3 months because it was queued with a lot of other "to-do's" to  
compete with each of them for a valuable programmers time. We are in a security  
oriented list so security takes precedence here. Go to the DNS groups, or  
sendmail, or nfs, or whatever. Whatever the topic, rest assured, it will be the  
priority within that group. All of them filter into Sun (or any other vendor)  
who must weigh each on it's own merits and prioritize them. Sure Sun could hire  
more programmers and reduce the turnaround time...but that cost would be passed  
directly to the customer...remember, the customer that is unwilling to bare any  
additional cost. Say for example that there are 100 current problems that need  
to be patched, and further say the cost of Solaris is $100, and it would raise  
the cost per unit by 2% to commit new programming resources to fix one patch  
immediately. If you arrange to fix all 100 problems immediately (which you  
would have to do to please everyone) then the 'improved' Solaris would cost  
would now cost THREE TIMES AS MUCH. Do you think folks would be please to trade  
90 days of response to an obscure exploit if it was going to triple the cost of  
the product. Absolutely not. Why doesn't everyone pay for 24/7 1 hour on-site  
repair response? Same reason. Sure they would LIKE to have it, but they don't  
want it badly enough to justify the additional cost.  
  
At this point you should start to be humming the tune I'm playing - Cost/Benefit  
Analysis. There are only two motivations for Sun to disregard the problem queue  
and commit immediate resources to a problem (1) it is a widespread problem that  
is CURRENTLY having an immediate impact on users (customers), (2) a large  
percentage of Solaris users indicate to Sun that they are so concerned about the  
POTENTIAL problems that they are willing to accept the marginal costs of  
committing additional resources to fix it immediately. That's about it.  
  
If you didn't notice, I just answered the very first question asked : "You pay  
for this?" Answer is No, you aren't paying for it. And most are content to  
wait for some period to AVOID marginal costs. In a sense cost/benefit is a form  
of security. Exercising it is a form of providing the security that you will  
still be solvent next year. Of course a shorter answer to the question "You pay  
for this?" is NO, because Solaris is now FREE to most types of users :) Sorry,  
I couldn't resist a little humor.  
  
Next question:  
  
[] How many security vendors knew about this and said nothing?  
[] Why did CERT never report this? Why have hackers  
[] been passing these exploits around for two years?  
[] Why didn't the ueber-spies of the ICSA get their  
[] hands on this and report it?  
  
I'm starting to suspect that Mr. Corruptio is not taking his Lithium (or is  
self-prescribing something else). Do I smell a a suggestion of a coordinated  
CONSPIRACY??  
  
No!  
Real answer: None! Security vendors make there living by being the first to  
find problems. Rest assured that if someone knew of it...you would have heard  
it here first. Why don't they know about it? I would suggest because it is not  
nearly the catastrophic malady that Mr. Corruptio makes it out to be. If memory  
serves from a quick `grep -i if corruptio.letter| wc -l` I think there were  
around 7 or 8 conditions that had to be met to even render a machine vulnerable.  
rpc.statd has to be running (the first thing most security aware folks comment  
out). Automountd has to be available. OK so afar I'm concerned...but wait, here  
comes the hook. OOPS, the 2.6 2.7 rpc.statd has changed so now you not only  
have to spoof your IP, but 'bounce' it off the target's pri/sec nameserver - the  
details of which are "left as an exercise to the reader" - something that Caspar  
Dik addressed recently. Of course if you want to short cut this "remote"  
exploit, you can log into the machine, su to root and modify the /etc/hosts file  
with the actual code - not a very useful exploit.  
  
I just picked 20 Sun's at random, spread over several actual production  
locations. I received permission from the local owners to do this. I didn't  
look to see if rpc.statd was up or not, I just picked them at random. This  
attack failed 100% of the time. Now, I'm not saying the details are in error.  
I am saying that if it doesn't affect any of 20 random machines it isn't too  
much of a problem in the real world. Certainly not a problem that -  
cost/benefit again - customers would be willing to pay a premium for to get  
fixed overnight. I'd also note here that Sun has comments in the inetd.conf  
file warning users that security aware sites often disable the 'r' stuff, etc.  
  
  
[]Or, is this a case of job security by one of Sun's engineers?  
[] We certainly feel it is the latter.  
  
Well this one is simple to answer. What job security is there in making a bad  
patch? To assume that such practices promote your longevity at a job is to say  
that Sun likes and rewards poor programming as the preferred practice. I'm  
fairly certain that no one believes that.  
  
[] The cache of the remote system can be found by establishing a  
[]connection to port 23, or port 21 of the system. The cache will  
[]usually appear inside parentheses, and will be the hostname of the  
[]machine.  
[]  
  
Anyone want to explain this one. I've logged into a lot of Solaris machines and  
I'm not at all clear what this parenthesis's refers to. Let's try a stock out  
to the shrink-wrap machine:  
  
[/aaa]198#: telnet bloomer.xxx.org 23  
Trying 10.10.10.9...  
Connected to bloomer.xxx.org.  
Escape character is '^]'.  
  
Hmm...no parentheses ...ok keep going  
  
login: johnqp  
Password:  
Last login: Sun Jan 3 20:10:56 from bufu.xxx.org  
Sun Microsystems Inc. SunOS 5.7 Generic October 1998  
[bloomer:~]2%:  
  
  
  
Enough...I know what he's talking about...but I'll be darned if I'm sure whether  
or not he does.  
  
  
  
[] Since then, it has been a downhill roller coaster for the boys and  
[]girls at SUN. Now, not only is 2.5 affected, but 2.5.1 stock, 2.5.1  
[]patched, 2.6 and 2.7 are all affected as well.  
  
  
My only comment is that Mr. Corruptio has quite a flair for the dramatic.  
Downhill? How so? Has anyone actually exploited this? No security companies  
or CERT knew of it (by Mr.Corruptio's own statements). If downhill is defined  
as gaining market share, being the dominant UNIX OS, having your stock triple in  
price, your CEO favorably protrayed on 60 Minutes as the only company with the  
guts to stand up against a REALLY bad OS like Windows, shipping more hardware  
that ever, bringing UNIX workstation pricing smack into the middle of the PC  
price range, inventing Java, and Jini - if all that is downhill then I'm getting  
my skis on.  
  
[] Why didn't Sun's own "security analysis team" of 70 people find  
[]this bug (or any others)? Could it be job security? We think so.  
  
<sigh> Again I'm unclear how a security team that fails to report security  
problems can be perceived to be a positive career move. And "Security Team" ?? I  
have this mental picture of a bunch of "computer firemen" sitting in a room...a  
bell rings and they all quit watching Oprah and jump into their freebie vendor  
T-shirts, slide down a poll, and run into a specially equipped secure clean-room  
to attack some bizarre new threat to man-kind. I would suggest that Sun's  
Security Team is more likely a bunch of folks with specific specialties (and  
many other job functions) that are consulted once some problem is reported.  
They are unlikely to be sitting around constantly trying to hack into their own  
OS. If I was a Sun stockholder and I found out Sun was paying 70 senior level  
programmers to sit around and try breaking into it's own OS, I'd be very upset.  
I would consider that to be very irresponsible corporate behavior. Mr.  
Corruptio - wake up - this isn't some academic exercise. This is a corporation  
trying to survive and flourish in the most inhospitable environment there ever  
was - a highly volitle computing industry that is donimated by a true piece of  
crap company.  
  
There is certainly more to Mr. Corruptio's letter to poke holes in, but I've  
already gone on too much. So let me leave you with this thought. Suppose I  
pull out the one suit I own (assuming it still fits), and show up at your  
business with only two products to sell. One is the most used and respected  
UNIX OS in the world. I tell you it runs a VERY high percentage of commercial  
and university servers in the world. It has an excellent suite of tools, and  
more software ported to it than any other UNIX. And, I tell you, it is secure  
against 99.9% of all types of exploits. And the price of this fine product is  
-- FREE! The other product I sell, oh well, it is the same product but it has  
undergone a no-holds-barred, no-expense-spared process to render it 100% safe  
against any and all types of exploits. The price? Oh well...it's $28 million  
per instance. This scenario is just about accurate. That last .1% would eat up  
more resources than it took to accomplish the entire first 99.9%. THIS is why  
cost/benefit was born. To STOP someone from doing something so foolish.  
Because every dollar you spend attacking that last 0.1% is a dollar you CANNOT  
spend on something else - because it is gone. Dollars are finite resources  
that must be spent where they can be the most effective - something that is not  
generally dictated by some script-kiddie pointing to an obscure (and highly  
conditionally dependant) exploit that by his own admission has not exactly been  
a hot topic among the security conscience.  
  
Should Sun address this problem - certainly. And anyone who is concerned about  
it should call Sun and file a bug / security report. Should Sun drop everything  
and commit all it's programming resources to this problem? I think the prudent  
individual would agree to the fallacy of that approach.  
  
I'll close by suggesting to Mr. Corruptio Optimi Pessima that when bashing  
companies, or anyone else for that matter, it is generally regarded as good  
manners to at least have the fortitude to stand behind what you say by signing  
your real name ( and thus your reputation ) to the words.  
  
Like this:  
  
Scott Stubbs  
bernadette.net  
  
Thanks for your time - and repeat after me just one more time - COST/BENEFIT !  
  
-----------------------------------------------------------------------------  
-----------------------------------------------------------------------------  
  
Date: Tue, 5 Jan 1999 10:04:06 +0100  
From: Casper Dik <[email protected]>  
To: [email protected]  
Subject: Re: SUN almost has a clue! (automountd)  
  
> If pathetic.sun.com were a Solaris 2.7 machine with pathetic  
> as its hostname, and a vulnerable Primary name server,  
> an exploit attempt would look like this:  
>  
> Execute commands to spoof reboot off Primary NS here  
> ./amountdexp pathetic.sun.com pathetic reboot 1  
>  
> If pathetic.sun.com were a Solaris 2.5.1 machine with pathetic  
> as its hostname, an exploit attempt would look like this:  
>  
> ./amountdexp pathetic.sun.com pathetic reboot 0  
  
  
Since tehre's no such thing as Solaris 2.7, I'm surprised it works tehre.  
  
Did you perhaps try it on the beta?  
  
My Solaris 7 system complains:  
  
Jan 5 09:47:31 room101 automountd[222]: Illegal access attempt by uid=1 - reque  
st ignored  
Jan 5 09:47:46 room101 statd[217]: statd: cannot talk to lockd at room101, RPC:  
Timed out(5)  
  
  
Statd doesn't run as root in Solaris 7 so the automounter will ignore its  
requests. This change was made late in Solaris 7 development and did not  
make it into any external release.  
  
The easiest way to work around this problem quickly is runnign statd  
as a user other than root, to this end change in /etc/init.d/nfs.client  
as follows (but not on Solaris 7, where such a change may break statd)  
  
  
28c28  
< /usr/lib/nfs/statd > /dev/console 2>&1  
---  
> su daemon -c /usr/lib/nfs/statd > /dev/console 2>&1  
  
(make sure you keep the links in /etc/rc?.d/[SK]*nfs.client pointing  
to /etc/init.d/nfs.client)  
  
and run:  
chown -R daemon /var/statmon  
chmod -R og-w /var/statmon  
  
Then stop and start lockd & statd.  
  
Casper  
  
`