[VulnWatch] Reality of the rpc.mountd bug
From: tb0b (tbob_at_primitive-incision.co.uk)
To: <firstname.lastname@example.org>, <email@example.com> Date: Mon, 14 Jul 2003 22:23:11 +0100
I was very saddened today to see the death of yet another privately
exploited unpublished bug in the form of the off-by-one in the nfs-utils
However, I feel the severity of this has been overstated and that the claim
that this can be used to execute abitrary code is slightly exaggerated.
Without going into too much detail I'm just gonna drop the header from my
original exploit for this.
BTW, this exploit has been circluating on EFnet for I would say about nine
months now so if you want it that badly (seen as it's almost totally
useless) go beg the divine intervention. I'm sure he would be glad to help.
/* mdx - x86/linux rpc.mountd remote root exploit.
* By tb0b - January 2002
* FOR PRIVATE USE ONLY - NOT FOR PRIVATE OR PUBLIC DISTRIBUTION.
* As mountd crashes if a 900+ byte string is sent as a mount request, I do
* doubt for one second that this has been found and actively exploited by
* others before now. It is not trivial to exploit, however.
* Some distributions of rpc.mountd will not segfault. This is due to the
* of gcc with which they are compiled. At the moment RH 7.0, 7.1 and 7.2
* known to use a version of gcc which does not correctly save ebp on the
* and are therefore not supceptable to off-by-ones AT ALL.
* * The vulnerability is still present in the latest source distribution. *
* LSB of frame pointer is corruptable with a single NULL byte. The area
* pointed to by this corrupted frame pointer is zero'd memory which we
* control. However, we are able to pass an arbitary ponter to free via the
* stack corruption and this can be used to place a pointer to shellcode in
* the memory area referenced by the resulting esp and allows us to exploit
* mountd with reasonable reliability.
* "Infatuated with this freedom, say the words and I could be them."
If you happen to be someone running RH 6.1/6.2 default rpc.mountd
unfirewalled then you should probably upgrade, everyone running an linux
more recent than this will be unaffected, as they will be by all stack-based
off-by-one bugs. gcc 2.95 4 life :)
iSEC security research need to actually *do* some research before publishing
in the future.
--- http://bitterness.primitive-incision.co.uk/ --- Dirty Hacker Style --- `Who said anything about cutting you up man? I just wanted to carve a little `z' on your forehead.'