full-disclosure - Undisclosed Sudo Vulnerability ?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20050802064547.GA21963@mantra>
Date: Tue Aug  2 07:40:48 2005
From: ben.hawkes at paradise.net.nz (Ben Hawkes)
Subject: Undisclosed Sudo Vulnerability ?

On Mon, Aug 01, 2005 at 09:57:51PM -0500, Ron wrote:
> Haha nice, I was just getting ready to run it on my sacrificial VMWare
> box, but you saved me the trouble of hitting "undo" :-)
> 
> Kurt Seifried wrote:
> > This is a trojan that will nuke all the files owned by the user running it.
> > 
> > -Kurt
> > 
> > ----- Original Message ----- From: "Esler, Joel - Contractor"
> > <joel.esler@...rt-s.army.mil>
> > To: <full-disclosure@...ts.grok.org.uk>
> > Sent: Saturday, July 30, 2005 12:40 PM
> > Subject: [Full-disclosure] Undisclosed Sudo Vulnerability ?
> > 
> > 
> >> About two weeks ago, our proprietary LIDS detected some suspicious shell
> >> activity on an internal .mil machine i am in charged of. Our server runs
> >> latest up2date Debian GNU/Linux on 2.4.31 x86 with grsec/PaX enabled.
> >> Before shutting down the machine and reinstalling it from scratch, we
> >> installed sebek module to monitor all shell activity. Based on the data
> >> we gathered, it seems the attacker gained root privileges using an
> >> undisclosed bug in latest sudo.
> >>

I don't know if anyone has mentioned this as I just got back on the
list, but the technical side of this is actually pretty impressive.
Of course, the malicious shellcode is always going to give away a fake
exploit, but the way in which this specific piece of code diverts the 
execution path from binary to the "shellcode" is particularly devious.

So I did a quick sweep of the code, and normally it takes about two seconds
to spot the line that diverts execution (things like function pointers
set to the "shellcode" or fairly obvious overflows). But this time I
couldn't see anything that would obviously cause the redirection, just a
few strange casts. So I fired up gdb, and was eventually led to the fact
that alloca() was treating the second #define as a byte argument.
Combined with the fact that alloca() performs 16-byte alignment, the
second of these calls was effectively equivalent to alloca(0).

Obviously this results in an overflow of the saved return address on
the stack, which results in the diversion. The other interesting thing 
is that the shellcode is very purposefully appended to the .text section, 
which as I see it can only be for one reason, PaX evasion. 

Certainly a waste of time, but a reasonably interesting and insightful 
waste of time nonetheless.

-- 
Ben Hawkes (fiver)
http://pie.sf.net/