Re: How to develop a random number generation device

On Sat, 15 Sep 2007 10:37:53 -0700, MooseFET wrote:

No a buffer overrun is over running the buffer. It doesn't matter
what is in the memory you've over run into.

Yes. Well, it matters in terms of what happens next, but not in terms of
whether or not a "buffer overrun" has occurred.

So you agree at this point.

Yes; subject to the caveat that the term "buffer overrun" is normally used
in reference to the exploitable case, where the overrun occurs between
buffers within the process' address space. E.g. the wikipedia entry for
"buffer overrun" or "buffer overflow" only addresses this case:

http://en.wikipedia.org/wiki/Buffer_overrun

Technical description

A buffer overflow occurs when data written to a buffer, due to
insufficient bounds checking, corrupts data values in memory addresses
adjacent to the allocated buffer. Most commonly this occurs when copying
strings of characters from one buffer to another.

The case where the buffer is at the beginning or end of a mapped region,
and the overrun attempts to modify a different region, is usually ignored.
The OS will just kill the process, so there's no exploit potential, and
it's statistically far less likely (most buffers aren't at the beginning
or end of a mapped region).

The exploit that takes advantage of the buffer overrun, causes an
overrun onto the return address or some other data that shouldn't be
writable by this task.

No.

Yes go back a re-read it carefully.

What's to re-read? Exploitation requires the write to succeed, which
requires that the overrun has to occur into memory which is writable by
the task.

Leaving aside whether the return address "should" be writable (that's
how the code which most compilers generate normally works; whether or not
that's a good idea is a different matter), the term "buffer overrun" is
normally used where a process overruns one variable or field (which is
part of the memory which the process is allowed to modify) and corrupts
another variable or field (which is also part of the memory which the
process is allowed to modify

You seem to be confused about what we are talking about.

I know what *I'm* talking about, which is what most programmers mean by
"buffer overrun", i.e. the exploitable case, not the segfault case.

We are
talking about making an OS safe. If an application task commits an
overrun that causes that task to fail, it is quite a different matter
than talking about a buffer over run based exploit.

The segfault case is uninteresting; it's a "solved" problem. The
exploitable case is one of the main mechanisms through which computers get
hacked. It's *the* main mechanism for most C/C++ code.

The is exactly what Mr. Larkin said was the case and he is correct in
that.

Mr. Larkin appeared to be talking about a different issue (process
isolation).

He is talking about process isolation and it not being violated by a
buffer overrun if the OS is well written. He is correct in what he
said.

Indeed. But none of the current OSes are defective in this regard.

Windows 95/98/ME lacked memory protection on certain parts of memory for
backwards compatibility (i.e. portions of the bottom megabyte were shared
between processes and globally writable, for compatibility with real-mode
(8086) code.

And this case isn't what people are normally referring to if they're
talking about "problems", "vulnerabilities" etc of buffer overruns.

When the overrun corrupts the process' own memory, the process continues
to run as if nothing untoward has happened, but it is now doing the
bidding of the attacker.

You have assumed that by causing the over run the attacker has gained
control. As I explained earlier this need not be the case.

An attacker *may* gain control through this mechanism. Whether or not they
can depends upon how the variables are laid out in memory and how the
variables affect the program.

The point is that protection against this issue mostly has to be done by
the language and/or compiler.

.

Relevant Pages

  • Re: Discovering variable types...
    ... >- but I suppose MS expect us to use wrappers ... memory allocations for your variables from disk as well. ... >They most certainly are of fixed size, changing the size of a String ... >>me to keep buffer size and current postion right in the memory block. ...
    (comp.lang.pascal.delphi.misc)
  • Re: Discovering variable types...
    ... >memory it points to is on the heap. ... sequentially reading data, if one is randomly reading records, then a ... >project is what's prompting me to improve disk access. ... from a memory buffer I can do it in about a second. ...
    (comp.lang.pascal.delphi.misc)
  • Re: Multicast Directshow Graph Bridging, COW Rustling, & the Use of Portable Holes in Cartoon Ph
    ... memory to share buffer pools across processes and works pretty well. ... You get two basic Direct Show filters, ... issue each GMF-source a virtual memory alias with COW ...
    (microsoft.public.win32.programmer.directx.video)
  • Re: PCI bus-master and large contiguous memory buffers
    ... I built my scatter gather list in SRAM that was on my device, ... could have done it in system memory had I needed to. ... interrupt when a buffer was filled, the application would save the buffer to ... beginning of the recording I made a device IO control call to my driver. ...
    (microsoft.public.development.device.drivers)
  • Re: PCI bus-master and large contiguous memory buffers
    ... As soon as device reaches the end of the buffer ... Sure, I am developing both PCI adapter and device driver, so, it is ... not afford reinitializing DMA on my device after every transfer. ... x86 CPU memory management structures I never tried to dig into Windows ...
    (microsoft.public.development.device.drivers)
Loading