Re: Buffer over-run vulnerabilities

From: P Gentry (rdgentry1_at_cablelynx.com)
Date: 02/25/04 

Date: 25 Feb 2004 11:36:45 -0800

andy@wild-flower.co.uk (AndyJ) wrote in message news:<e310d7ea.0402250238.245b06ae@posting.google.com>...
> Just a thought (from a complete newbie)...
>
> Firstly, If I understand correctly, a Buffer Over-run *Vulnerability*
> occurs when data ...

More commonly (via stack buffer overruns) the inserted "data" contains
an short piece of code that is executed when the calling function
(that contains the buffer var) returns -- but the return address has
been changed to jump to the inserted code (egg).

> ... is inserted into a buffer (patch of memory) without
> first checking whether or not the amount of data will fit into the
> allocated space. Any data beyond the length of the buffer "spills
> over" into the memory following the buffer, overwriting its contents.

And this is a pretty fair description of a heap based overrun, which
is not dependent on the "structure" of the stack, but on the structure
of the heap var.

> Secondly, IIUC, a Buffer Over-run *Exploit* exists when there is a
> section of program code stored in memory at some point after the
> buffer, and the overflowing data contains executable program code that
> will spill over into the area containing the program code.

See above. The "placement" (location) of the code and getting it to
execute is tricky and specific to each exploit, but the _principal_ is
the same and well understood. Stack (local vars) and heap
(dynamically allocated memory) based overruns operate a bit
differently. See ref below.

> Subsequently, the attacked program is then 'persuaded' to run the
> injected code (by causing it to follow a given path of logic that
> eventually leads to the processor executing the code). ...

Especially so with stack based exploits -- when a function returns it
jumps back to the point from which it was called while the exploit
causes it to jump to the injected code instead. It's just taking
advantage of how stack based vars and code work.

> ... This code can,
> of course, perform actions other than those which the program was
> originally intended to perform.
>
> Am I right on those two? Close enough, maybe? (I am not a C/C++
> programmer, but I do program).

Close enough to get by and good enough to understand a better
description and examples than I can give here.

> So, a question: Under Linux, is the arrangement of a program's data
> segments in memory determined at *compile* time or *load* time?

The stack operates the way it does out of "necessity" and is built
into the compile time code. There are ways to use a non-executable
stack. Heap overruns need to get to the vulnerable spot in heap
memory, so they need a way to get a pointer to the right location --
this is usually done by knowledge of the vulnerable code structure
(and sometimes some good detective work with a decompiler).

> Either way, is there a way to *randomise* (or otherwise perturb) the
> locations at which the code is actually loaded into memory, ...

You don't really have any control over the "absolute" location of code
or data on the heap and that which is placed on the stack must be
placed in specific (if automatic) ways.

> ... so that
> you could never be sure of the sequence? This would, of course, break
> any programs which do pointer-arithmetic that rely on where things are
> 'supposed' to go, but would this be very often? Is this practise not,
> in fact 'bad style' anyway?
>
> My point is, can Buffer Over-run Exploits be 'cut off at the pass', so
> to speak, or is this just fantasy?
>
> -andyj

Your solution is a variation on the principle of "security through
obscurity" , ie., hiding things good enough that others won't find it
without the "secret knowledge" of how to get there. Makes getting
there harder, but once there the same vulnerability exits to be
exploited. The cure is to fix the vulnerability (the disease) rather
than obscuring its presence (the symptoms).

The net has tons of stuff on buffer overruns that will range from
basic definitions to concept code for specific exploits (and exploit
code also, if you care to find it). I pulled up this while responding
to your post and it will get you started with a better description and
two "classic" references on buffer overruns:

Google search was: buffer overrun l0pht
http://216.239.41.104/search?q=cache:2LbHxLXdYMIJ:www.rootsecure.net/content/downloads/pdf_downloads/buffer_overruns.pdf+buffer+overrun+l0pht&hl=en&lr=lang_en&ie=UTF-8
http://www.rootsecure.net/content/downloads/pdf_downloads/buffer_overruns.pdf

hth,
prg
email above disabled

Relevant Pages

  • [NEWS] How to Remotely and Automatically Exploit a Format Bug
    ... Exploiting a format bug remotely is not as difficult as one would think. ... We will use very minimalist server along this paper. ... Since the buffer is directly available to a malicious user, ... Guessing the address of the shellcode in the stack ...
    (Securiteam)
  • [NEWS] Multiple ValiCert Security Problems
    ... * Enterprise VA Host Server for processing validation requests VA API ... Multiple buffer overflows exist in the CGI script, forms.exe, which is ... Analysis of the code and stack contents reveals that the unchecked buffer ...
    (Securiteam)
  • [REVS] Buffer Overflow Exploitation and Prevention
    ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... you have to know what a buffer overflow is (we highly recommend reading ... to by `str' is too long, we smash, outside of the buffer, EBP (not always ... We'll have to appropriately prepare the stack in order for our ...
    (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)
  • Re: PB 4.1 - how to FTP without WinInet library ?
    ... not changing the scope or type of buffer. ... Let's assume it overflowed stack, ... product started to work normally with Httplite DLL, ... confers no rights. ...
    (microsoft.public.windowsce.platbuilder)
Loading