Next Page >>
return address
requirements to achieve the concept that a polymorphic code must be
unpredictable, and it means random. I choose the MS02-039[1], because I have
all the requirements for this proof of concept:
1. Microsoft Windows Buffer Overflow[2];
2. Buffer to overflow is not too big;
3. More than just one Return Address[3];
4. Incredible high number of writable addresses only in
SQLSORT.DLL[4].
-[ MS02-039 Exploit Structure
int main ( void )
{
unsigned int original_address;
unsigned int memcpy_address;
unsigned int return_address;
unsigned int jmp_address;
unsigned int code_address = 0;
unsigned int pos;
char buffer [ 0x1000 ];
char cmd [ 4096 ];
- later this data is handled as a string but no final NULL byte
delimiter is inserted
- there is also an off-by-one bug since one byte overwrites the lower
8bit value of a saved element (a stack pointer 017bff??)
- after this buffer are located some pushed elements and obviously the
return address of the function
- it calls the OemToChar API that changes some bytes of the buffer
(like those major than 0x7f) till it reaches a 0x00 that "luckily" is
after the return address
- so also the return address gets modified, exactly from 0084cb18 to
00e42d18 that ironically is a valid stack frame somewhat related to
+ pr3st0 +
$ ./dropvax X.X.X.X -12345
[+] ATDT X.X.X.X
[+] CONNECT 9600
[+] Return address: 0xUWISH
[*] Compiled for little-endian arch.
[+] Sent payload...
[+] Shell!
4.3 BSD UNIX #3: Sat Feb 14 20:31:03 PST 2004
16:56 up 6:08, 1 user, load average: 0.09, 0.06, 0.03
B] partial track buffer-overflow
--------------------------------
Another buffer-overflow is exploitable through the packets with ID 10
but this time doesn't seem possible to use it for executing remote
code because the return address is overwritten by a fixed string of the
server.
In short when the user requests a track which is not available on the
host, the server calls:
a purpose beyond getting our answer back to original sender. We attach
a meaning to these addresses. If we see john.smith@example.com, we
expect that we're really sending a mail to someone at the Example
company.
We may have learned not to trust the "From" address: that's about as
unreliable as the return address on the back of an envelope. But we
should be careful with what we think we see in To-field too.
Problem
=======
The problem comes from the unicode "right-to-left override" (RLO,
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@localhost # echo `perl -e 'print "a"x1000'` | nc -v dahmer.vistech.net 79
---------
<img width=0.3133731337313373133731337... src="31337.jpg">
---------
Play little bit with numbers to get a desirable return address, little
bit of heap spraying, and it works.
Regards,
Leon Juranic
The methods SaveasMolFile and ReadMolFile are both vulnerable to
a stack overflow condition which can be reached when supplying
more than 400 white-space characters in the filename argument.
Both tab and space characters can be used to trigger the overflow condition.
The 401-404th byte will result in the overflow of the call stack return address.
Both vulnerabilities can be used to gain command execution when combined
with a JavaScript heap spray when jumping into a pre-allocated heap.
+--------+
|Solution|
"\x80\xe8\xdc\xff\xff\xff/bin/sh";
char buffer[MAX_BUF];
// fill the buffer with the return address
//the address to be overwritten is 524 bytes from the addr of buffer
for (i=0; i<MAX_BUF; i+=4)
*(long *)&buffer[i] = RETADDR;
Vladimir '3APA3A' Dubrovin wrote:
> Dear Guido Landi,
>
> For DoS - yes, you can use existing file, but it's (almost) impossible
> to create reliable code excution exploit since you can not (fully)
> control return address, like required in JMP ESP technique used in this
> exploit.
>
> --Wednesday, September 2, 2009, 12:33:47 PM, you wrote to 3APA3A@SECURITY.NNOV.RU:
>
> GL> no, MKDIR is *not* required, also write access is *not* required.
commands (ever using the server as a "bridge"), in the case of the SAY
command we will have that the server sends max 512 bytes of data for
this command and an unicode buffer-overflow happens in the client if
receives a SAY of over 1024 chars.
The only limitation is that the attacker (client) doesn't seem to be
able to control the return address because it's overwritten by the
subsequent command sent by the server:
SAY 0;nick: aaa...aaa??@SAY 0;nick: aaa...aaa??@COMMAND
first 512 bytes second 512 bytes subsequent command
Remote exploitation of a stack buffer overflow vulnerability while
handling specific HTML tags in Microsoft Corp.'s Internet Explorer web
browser allows attackers to execute arbitrary code within the context
of the affected user.
On Internet Explorer 5.01 a function return address can be overwritten
with attacker controlled data which results in an exploitable
condition. However on Internet Explorer 6 the vulnerability will only
overflow one byte. For Internet Explorer 6 on Windows 2000 platform,
the overflowed byte is in a local variable, and overwriting it doesn't
affect program execution at all. For Internet Explorer 6 on Windows XP
I was asking if ws2_32.dll was compiled with SafeSEH (didn't know about the Olly plugin). Regarding the return address...I already have control of EIP, but can't point it directly to the stack, so I'm searching for a module with a suitable return address (with pop/pop/ret) to help me get back to that buffer. The issue was with the return address I was pointing to, and the fact that it the module was compiled with SafeSEH. Is that enough detail?
Correct! But, if you can do it with an extra elegance, it is better, isn't it?
>> Now, we know how we must build the exploit, and I think we can do a great
>> job randomizing all the fields. Here are the fields ENG needs to deal with:
>> attack vector, buffer, return address, jumps, writable address, nops, and
>> shellcode.
> This is what most of us would call "obfuscating an attack", or "mutating
> an attack". Just so that you know, a tool named SPLOIT was already made
> to perform a number of mutations over exploits (at this and other levels).
If the hostname is 99 characters or longer then the overflow occurs as
the result of a call to the sprintf() function. Although this is
technically a stack overflow, because IOS allocates heap memory for
process stacks, the memory overwritten is actually heap. However, as the
heap memory is acting as a stack, the return address, stored before the
start of the character buffer, can be overwritten by the hostname when
the overflow occurs, but for some reason the crash doesn't occur until
the buffer intrudes into the "red zone" at the boundary of the heap
chunk. Therefore, when the crash happens and the router reboots, the
memory dump indicates heap corruption.
Dear Guido Landi,
For DoS - yes, you can use existing file, but it's (almost) impossible
to create reliable code excution exploit since you can not (fully)
control return address, like required in JMP ESP technique used in this
exploit.
--Wednesday, September 2, 2009, 12:33:47 PM, you wrote to 3APA3A@SECURITY.NNOV.RU:
GL> no, MKDIR is *not* required, also write access is *not* required.
You're right, there is no check against FD_SETSIZE. IMO it's a bad idea not to enforce some kind of accepted connections limit. However, I'm pessimistic about the possibility of executing arbitrary code - even if you succeed to overwrite the return address, you must think of some other way to place "evil code". Of course, nothing is impossible :)
BTW, my PoC code has some pretty dumb bug, char hostname[12] should be char hostname[15]...stupid me, I forgot about the dots in the ip address :)
test made using the latest version of Quicktime on Mac OS X 10.4.11 PPC
and Mac OS X 10.5.1 Intel:
http://forum.macbidouille.com/index.php?act=ST&f=8&t=251685#entry2512134
On both the platforms the code flow has pointed to the return address
specified in the proof-of-concept (on PPC 0x01010119 is just the 0x01
sequence of bytes which was in my PoC before the 'A' sequence).
Anyway this mail is also for pointing out a new
customizable proof-of-concept which I have written yesterday and that
"\x61\x61\x61\x61" /* padding */
"\x61\x61\x61\x61" /* padding */
"\x61\x61\x61\x61" /* padding */
"\x61\x61\x61\x61" /* padding */
"\x80\x06\x23\xB8" /* return address */
"\x0d\x0a";
/* trampoline code */
/* when the overflow occurs r26+0x14 points to the shellcode */
/*
> 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)
>
On Thu, Aug 07, 2008 at 12:08:53AM +0100, Shaun Colley wrote:
> 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).
Hahahaha, welcome to 1988!
Alex
Quoting jeremy.junginger@gmail.com:
> I was asking if ws2_32.dll was compiled with SafeSEH (didn't know
> about the Olly plugin). Regarding the return address...I already
> have control of EIP, but can't point it directly to the stack, so
> I'm searching for a module with a suitable return address (with
> pop/pop/ret) to help me get back to that buffer. The issue was with
> the return address I was pointing to, and the fact that it the
> module was compiled with SafeSEH. Is that enough detail?
>
> On Thu, Aug 07, 2008 at 12:08:53AM +0100, Shaun Colley wrote:
>> 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).
>
> Hahahaha, welcome to 1988!
Old software can be so much fun.
"\x61\x61\x61\x61" /* padding */
"\x61\x61\x61\x61" /* padding */
"\x61\x61\x61\x61" /* padding */
"\x61\x61\x61\x61" /* padding */
"\x80\x06\x23\xB8" /* return address */
"\x0d\x0a";
/* trampoline code */
/* when the overflow occurs r26+0x14 points to the shellcode */
/*
maybe I have formulated badly this question. I mean that if we can overwrite return address of the function properly ( without access violation ) then we can overwrite SEH properly ( without access violation ) and if we can overwrite SEH properly then we can overwrite return address properly. So it seems ( for me ) that SEH overwrite is equivalent to return address overwrite. Since return address is more simple to handle, so there is no need to play with SEH. So why hackers play with it? ( I talk there only about defualt SEH, which is encountered during access violation - i.e http://www.milw0rm.com/exploits/4651 ) Maybe I miss something very important there.
best,
opexoc
if ( w == TRUE )
{
/* write a pop-pop-ret */
memcpy ( base + 0x10 , "\x58\x58\xc3" , 3 );
/* return address + 0x10 ( to avoid a zero in the address ) */
address = ( unsigned int ) base + 0x10;
}
}
/* if a matching address is found */
The Irc_Proto_ParseServerMsg(...) function parses server messages of up to 1024
bytes in length and writes to an irc_server_msg_t structure. This structure's
last field is a 512-byte string buffer. A malformed server response can cause
Irc_Proto_ParseServerMsg(...) to write past the end of the irc_server_msg_t
structure and overwrite the return address for Irc_Logic_ReadMessages(...).
=======
Exploit
=======
See below for a proof-of-concept exploit packet for UFO: Alien Invasion 2.2.1
The result is that after 1024 unicode chars the instructions will start
to get the unicode chars located in the output ascii buffer.
The input chars are unicode chars (16 bit) and so those in the ascii
buffer are ever major than the 256 number (0x0100) forcing the
instructions to continue to put 0x7f chars until a NULL byte is finally
reached... and in the meantime the return address has been completely
overwritten by 0x7f7f7f7f.
During my tests only UnrealTournament (version 451b) wasn't vulnerable
because its appSprintf delimits the destination unicode buffer.
------------------
This bug is not only the most dangerous of those I have found but it's
also the most interesting.
A buffer-overflow vulnerability is located in the function which
handles the packets with ID 0x80 or 0x88 but no return address is
overwritten, in fact the bug allows the modification of some buffers in
the server included the one containing its version.
For exploting the bug we need to query the server (UDP port 34297)
where will happen a second buffer-overflow caused by the creation of a
reply using the too long server's version set by the attacker.
Next Page>>
|
