Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
Subject: statdx2 - linux rpc.statd revisited
From: ron1n - (shellcodeHOTMAIL.COM)
Date: Wed Oct 11 2000 - 08:36:16 CDT
- Next message: Caldera Support Info: "Security Update: file view vulnerability in mod_rewrite"
- Previous message: Guenther H. Leber: "Re: Shred 1.0 Bug Report"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
I know this is getting old and boring now, but a lot of bugtraq readers
have sent me reports of problems experienced when auditing their systems,
and others have asked questions regarding the code's usage. Because of the
number of these emails, I decided to take down statdx from its dusty shelf
and remold it into something that will give more bang for the buck.
You know the drill -- use only in an ethical manner, don't destroy valuable
information, even domains five levels deep at the bottom of the global
interest hierarchy don't need a tagged HTML facelift, etc.
Attached is statdx2.tar.gz. It contains the following two files:
* gdb.txt - how to get addresses with gdb (requested often)
* statdx2.c - the exploit itself (bug fixes, new stuff)
In another instance of keyboard diarrhea, here's the new introduction:
*** statdx2 (the successor of statdx)
*** Linux rpc.statd remote root exploit
*** by ron1n <shellcodehotmail.com>
*** October 10, 2000
*** $ ./statdx2 -h
*** This version supersedes my original release. The reason I chose to
*** resurrect this stale exploit is so the new incarnation would contain
*** many improvements over the first version.
*** There are major changes in the algorithm used in the exploit buffer
*** construction. The format string now uses "%hn" to eradicate several
*** rare but possible problems. I didn't know about the "$" trick when I
*** wrote statdx. Even though it seems to be the new trend, I decided to
*** ignore it for this particular exploit. An additional payload has been
*** added to allow remote execution of arbitrary commands. This should help
*** when the port-binding code can't be used.
*** There is now primitive brute forcing code which slightly increases
*** your chances of a successful exploitation against any vulnerable i386
*** distribution of Linux. In order to implement this, the attack strategy
*** had to be altered. A progressive brute force climb down the stack to
*** hit the correct address of the saved return address will cause problems
*** when the saved frame pointer is overwritten. Instead, an overwrite of
*** the saved frame pointer is used to cause redirection in the parent
*** epilog code (see phrack-55). This is much safer to use for brute
*** forcing and has the side benefit of being an alternative avenue of
*** attack when the usual target address contains a null byte. The null
*** byte truncation problem still exists when brute forcing though, so
*** use common sense.
*** The information below is based on numerous questions I receive.
*** common reasons for failure
*** o Confusing statd with rstatd.
*** o Attacking an architecture that isn't i386.
*** o Attacking an operating system that isn't Linux.
*** o Attacking a different distribution of Linux with the
*** default Redhat exploitation variables.
*** o Attacking a system whose statd has crashed because of
*** previous exploitation attempts, successful or not.
*** The portmapper will still advertise statd even though
*** it will remain dead until restarted.
*** o Attacking a patched system or a system with stack
*** protection. Stack protection will defeat this exploit.
*** I have seen a way to deliver the shellcode elsewhere
*** using a different procedure call, but I am not going
*** to steal that idea.
*** important notes
*** o The attack may be logged in syslog target locations.
*** o Statd is a standalone service; be careful. Brute
*** forcing can be fatal. In fact, it's highly probable
*** that it will be fatal. The brute force mode exists
*** only to introduce a behavior-based form of blind
*** debugging with crashes mapping stack frames. This is
*** very difficult to do and it requires patience, but
*** it can be done.
*** o The nature of the vulnerability provides no means
*** to examine the stack remotely, afaik. If anyone
*** wants to drop me a free clue about this, email me.
*** dotslash examples
*** # default Redhat attack
*** $./statdx2 -d0 target
*** # default Redhat attack; new payload
*** $./statdx2 -d0 -c "touch /blah" target
*** # saved ebp overwrite (used automatically when desirable)
*** $./statdx2 -a 0xbffff2fc -f target
*** # brute force mode -- 50 iterations (-f option implied)
*** $./statdx2 -a 0xbffff004 -n 50 -s 20 target
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Share information about yourself, create your own public profile at
- application/x-tar attachment: statdx2.tar.gz