Re: solaris gdb screen mayhem

From: corecode (corecode@corecode.ath.cx)
Date: 08/30/01 

Message-Id: <5.1.0.14.2.20010830141348.027ecd28@spirit>
Date: Thu, 30 Aug 2001 14:21:26 +0000
To: ant@notatla.demon.co.uk (Antonomasia)
From: corecode <corecode@corecode.ath.cx>
Subject: Re: solaris gdb screen mayhem

At 09:51 PM 8/29/2001, 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.

nice idea... so you want to check if your boxes are still in
non-executable-stack state?
but you should write the "shellcode" on your own to fit your purposes. you
don't need a shellcode.

>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 ?

why don't you try this one: it would be enough to call exit(1) in the
"shellcode". so if the code on the stack gets executed, the program will
return 1 (== shell false). install a signal(SIGSEGV) and signal(SIGBUS)
handler that will exit(0);

good idea?

cheerz
   corecode 

--
http://www.eikon.tum.de/~simons/security/

Relevant Pages

  • [NEWS] Multiple Vulnerabilities in Stack Smashing Protection Technologies
    ... Stack shielding technologies have been developed to protect programs ... techniques to bypass those stack protection technologies, ... security vulnerabilities by overwriting a critical portion of a running ... GNU gdb 19990928 ...
    (Securiteam)
  • [REVS] Writing Buffer Overflow Exploits - a Tutorial for Beginners
    ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... Buffer overflows in user input dependent buffers have become one of the ... The bottom of the stack ... To keep it simple, shellcode is simply assembler commands, which we write ...
    (Securiteam)
  • [9fans] OS X threads + dynamic linking
    ... I need an answer to make libthread work on OS X x86. ... on the given stack. ... A gdb session running the program ... char stack; ...
    (comp.os.plan9)
  • Re: [9fans] OS X threads + dynamic linking
    ... on the given stack. ... A gdb session running the program ... It's dying in the dynamic linker trying to resolve printf. ... char stack; ...
    (comp.os.plan9)
  • Re: Sabotaged PaXtest (was: Re: Patch 4/6 randomize the stack pointer)
    ... the overflow hits field1 and whatever is deemed necessary from ... [field1 and other locals replaced with shellcode] ... [saved EBP replaced with anything in this case] ... (at which time the stack has already become executable). ...
    (Linux-Kernel)