Re: How to develop a random number generation device

On Sep 15, 10:13 am, Nobody <nob...@xxxxxxxxxxx> wrote:
On Sat, 15 Sep 2007 07:36:58 -0700, MooseFET wrote:
That doesn't address the issue, which was whether the OS can prevent
buffer overruns.

I can't prevent them, but it could and should trap them and abort the
offending task, with no possibility of subsequent damage.

Under a decent OS, bad code should only hurt itself.

I don't think you understand what a buffer overrun is. FWIW, it isn't
related to process isolation (preventing one process from trashing another
process' memory). That's a non-issue with modern OSes and modern CPUs (for
x86, that means 80286 and later).

A buffer overrun is where a process trashes its own memory. The memory
which is written is supposed to be written by that process, but the wrong
part of the program writes the wrong data to it (e.g. writing a portion of
a string to memory which is supposed to hold an integer or pointer).

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.


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.


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


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.



.

Relevant Pages

  • Re: c mex file problem -- incorrect results
    ... Sounds like a buffer overrun to me. ... the mex file stays resident in memory. ... Does it always give the correct answer the first time you launch Matlab ...
    (comp.soft-sys.matlab)
  • Re: malloc() causes an Access Violation when compiling with the /MT switch
    ... > x bytes and then writing exactly x bytes into the allocated memory... ... >>> it only happens with the non-debug builds of the CRT. ... Thus a buffer overrun of a few bytes may pass unnoticed. ...
    (microsoft.public.vc.language)
  • Re: More buffer overrun problems
    ... That's the galling thing about buffer overruns. ... "buffer overrun" message refers to memory buffers of course, ... iteration through the loop which caused the buffer overrun error. ... this isn't a VFP error I'm getting. ...
    (microsoft.public.fox.programmer.exchange)
  • Re: How to develop a random number generation device
    ... offending task, with no possibility of subsequent damage. ... related to process isolation (preventing one process from trashing another ... A buffer overrun is where a process trashes its own memory. ...
    (sci.electronics.design)