full-disclosure - Re: How to covert shellcode to "HTML style" ?

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>] [day] [month] [year] [list]

Date: Sat, 11 Nov 2006 15:33:55 +0100
From: endrazine <endrazine@...il.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: How to covert shellcode to "HTML style" ?

<take 2: had some issues in sending this one>

Hi list,

Knud Erik Højgaard a écrit :
> On 11/9/06, 李继辉 <lotos.lee@...il.com> wrote:
>> For example ,I find This exploit:
>
> http://www.edup.tudelft.nl/~bjwever/src/beta.c, have fun with your
> upcoming botnet.
Nod, encoding the shellcode into an acceptable charset is something that 
has been done for ages now (see
Philippe Biondi's shellforge - did you fix the final ret ? ;) - for 
instance, or old phrack issues [2] [3]).

Let's focus a bit on x86:
What about the return address if you have a simple buffer overflow for 
instance ? I just had a few
tests, and you can't simply urlencode the return address assuming the 
webserver/client will decode it
automatically for you (it won't). Since adresses in the stack are 
tipycally around 0xbf?????? in memory,
this return address _will_ contain non printable characters (at least 
the \bf one,), even if the overflow is
big enougth so that you can get rid of the other ones by jumping at an 
appropriate address in the stack...

I have no simple solution atm, but forging valid arguments for the 
current syscall that will eventually
do something evil in the process (wich isn't something that can be done 
in a systematic way) and _not_
overriting the return address.. You could think of crafting arguments 
for previous stack frames too, but
since you still can't forge return addresses for those, you will not be 
able to overwrite both local and
global variables pushed on the stack...

An other solution would be ret2esp [4], assuming you find :
1) a way to store your shellcode somewhere in memory, the address of 
your shellcode being a pure
Ascii string.
2)an address in memory that will allow you to jmp %esp (or mov %esp, 
etc.) , that address being
usable as a return address (ie: is a pure Ascii string).

I doubt those conditions will ever be met..

Things should be quite similar on Sparc architectures imho since afaik, 
the return address isn't pushed
on the stack, so the problem is very close to this one.

In a nutshell : Erik, I disagree with you, I think it's a valid, non 
trivial, question :)

Regards,

endrazine-

[1] http://www.secdev.org/projects/shellforge/ <---which isn't just ia32 
between :)

[2] http://www.phrack.org/archives/57/p57-0x18

[3] 
http://www.phrack.org/archives/61/p61-0x0b_Building_IA32_UnicodeProof_Shellcodes.txt 

[4] http://www.tty64.org/doc/expwlnxgateso1.txt

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/