full-disclosure - Re: [NETRAGARD-20060810 SECURITY ADVISORY] [HP Tru64 dtmail Unchecked Buffer - Local Root Compromise] [ http://www.netragard.com ]

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-next>] [day] [month] [year] [list]

Date: Fri, 20 Oct 2006 22:54:53 +0200
From: Roman Medina-Heigl Hernandez <roman@...labs.com>
To: "PERFECT.MATERIAL" <perfect.material@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: [NETRAGARD-20060810 SECURITY ADVISORY] [HP
 Tru64 dtmail Unchecked Buffer - Local Root Compromise] [
 http://www.netragard.com ]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

PERFECT.MATERIAL escribió:
> Correction, TRU64 runs on Alphas in LSB mode. However, this bug is still
> not exploitable. Sorry for the NETRAGARD-like fuckup :D

I didn't have time enough to test this, but at first sight it seems
perfectly exploitable.

Alpha is a "true" 64 bits RISC processor (both data & addressing being 64
bits), little-endian. A typical stack address is something like:
0x000000001ffff530 ( "\x30\xf5\xff\x1f\x01\x00\x00\x00" )

So yes, you have nulls (3, in this case), but at the end of the string :-)
You can try a typical string-alike buffer:
[ NOPs ... SHELLCODE RET ]
(stack variables are just before RET, you have not saved frame pointer
stored here)

Assuming a typical RET value (like the former one), your exploit should
rely on memory being "more or less clean", I mean, at least two nulls (the
third one is \0 terminator byte, you can insert it) should be exist in the
memory location where the attack string is being copied (well, at the end
of the string). Is this difficult? I don't think so (but I don't really
know for sure).

You can minimize the problem if you use longer RET addreses. For instance,
a typical address inside libc functions could be: 0x3ff800f3810 (so you
have two nulls, instead of three). You'd have to deal with only one
residual null value, instead of two. You can try this with a typical return
into libc exploit. This should be also sufficient (and useful) to avoid
non-executable stack protection, which is enabled by default in Tru64.

Well, that's the theory... :-)

- --

Saludos,
- -Roman

PGP Fingerprint:
09BB EFCD 21ED 4E79 25FB  29E1 E47F 8A7D EAD5 6742
[Key ID: 0xEAD56742. Available at KeyServ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)

iD8DBQFFOTed5H+KferVZ0IRAlWEAJ0YkY8LfGaqqYglNkuqj4ZDXwrJ8QCgvFIU
zyQhr3AP26MlKOVdKdk4Dio=
=Iga8
-----END PGP SIGNATURE-----

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/