Re: solaris gdb screen mayhem

From: Dave Aitel (daitel@atstake.com)
Date: 08/30/01 

Message-ID: <3B8E6360.6A364FDE@atstake.com>
Date: Thu, 30 Aug 2001 12:01:36 -0400
From: Dave Aitel <daitel@atstake.com>
To: Antonomasia <ant@notatla.demon.co.uk>
Subject: Re: solaris gdb screen mayhem

Throw some easy shellcode into the following little program (just write your
assembly in sub1() and you should have no problems with it getting all
messed up when you're doing your demos.) Fun as an overflow is to write,
you're probably better off just using a function pointer call (see main())
to demonstrate executability or non executability.

OR you could just load up any program in gdb and set $pc=$sp where $sp is
pointing to a nop of some sort, and do a si.

OR you could use adb and actually peek at the variable in kernel memory (if
you're root.)

ALSO don't forget "(gdb) maintanance info sections."

-dave

sub1()
{
/*insert your shellcode asm here*/
asm("

");

}

int
main()
{

  unsigned char buffer[4000];
  char * p;
  memcpy(buffer,sub1,400);
  p=buffer;
  ((void(*)())(p)) ();

}

Antonomasia wrote:

> I've been attempting a white-hat "exploit" to run some demo code
> on the stack on Solaris. The aim is to show whether the non-executable
> stack is in force (and the /etc/system file may not be a reliable guide
> to this if modified since last boot or something).
>
> So ideally I'd take a Solaris/sparc shellcode and modify "sh" to "id"
> and plant this in a program that deliberately overflows itself. And this
> will be run on various machines periodically.
>
> My problems arise when:
>
> Having got "execution" of the illegal string "AAAAAAAA" I replace
> it with downloaded shellcode and this disturbs the exploit so it
> needs some adjustment. I get a core dump from either SEGV or BUS
> and in trying to find the program state with gdb it throws garbage
> over the screen and is not recovered by "stty sane" or "reset".
> I suppose I could wrap gdb in perl and allow only filtered chars to
> my terminal. What do other people do about this ?
>
> Execution on a non-executable stack gets a SEGV. Is there a way
> the program can distinguish this from any other SEGV ?
>
> Self-choosing values for portability is likely to be a future
> puzzle if this is overcome.
>
> --
> ##############################################################
> # Antonomasia ant notatla.demon.co.uk #
> # See http://www.notatla.demon.co.uk/ #
> ##############################################################

Relevant Pages

  • Doubts in shellcode !?
    ... I'm reading a tutorial about shellcode, ... That will execute the /bin/sh. ... And we must, compile it, and open gdb and get the hex value with ... x/xb main+3 ...
    (comp.security.unix)
  • Re: Problem exploiting a CGI overflow
    ... Second, I wrote a shellcode without 0x0b,0x0c, but it didnt work because ... int main(int argc, char *argv) { ... $ ./post.cgi < buffer ... gdb: Symbol `emacs_ctlx_keymap' has different size in shared object, ...
    (Vuln-Dev)
  • Re: shellcode -> asm?
    ... shell code is in a the char array "shellcode". ... GNU gdb 2002-08-18-cvs ... For most of the attacks I have, ...
    (Vuln-Dev)
  • Re: Problem exploiting a CGI overflow
    ... looking at the gdb output- it looks like you are on the right ... There is a problem with the shellcode, ... >> char txt; ... >> Violación de segmento (core dumped) ...
    (Vuln-Dev)
  • Re: Problem exploiting a CGI overflow
    ... > Second, I wrote a shellcode without 0x0b,0x0c, but it didnt work because ... > int main(int argc, char *argv) { ... > char *buff, *ptr; ... > gdb: Symbol `emacs_ctlx_keymap' has different size in shared object, ...
    (Vuln-Dev)