Re: How to develop a random number generation device

On Fri, 14 Sep 2007 21:51:23 -0700, John Larkin 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).

Well, Windows is not a modern OS, and x86 is not a modern processor.

The 80286 and later have a built-in MMU, and Windows 3.1 and later make
use of it (although the 95/98/ME branch don't make quite as much use of it
as they should). With NT/2K/XP, processes don't trash each other's memory
(one process might "persuade" another to trash its *own* memory, but
that's a separate issue).

Given decent hardware tools, an OS should abort a process that tries
to execute data.

That feature is available at least on current Linux and BSD systems; I'm
not sure about Windows. It can break certain programs, e.g. those written
in languages which make extensive use of thunks (trampolines), as well as
some emulators and languages which use just-in-time compilation.

That doesn't *prevent* buffer overflows, but it prevents exploitation via
the "classic" mechanism (write "shellcode" into a stack variable and
overwrite the return address to point into the shellcode).

However, there are other ways to exploit buffer overflows, e.g.
overwriting function pointers, or data which affects control flow. If you
can't inject your own code, you're limited to whatever code is already
part of the process, but that may be more than enough (system() will
almost certainly be available; if you're lucky, there may be a complete
interpreted language available to use).

There was a joke, in the DOS days, that a certain jpeg file contained
a virus. It was a joke because it was obviously impossible. A few
years later, Windows managed to make it happen.

There's no technical reason why it couldn't have happened under DOS.

And XP occasionally crashes when a user-level process screws up. Not
as often as '98 type systems, but it still happens. And Patch Tuesday
has become a ritual.

But that almost certainly isn't due to the user-level process directly
trashing OS memory. It's far more likely that the user process passes
"bad" data to the OS and the OS trashes its own memory.

The reason why the OS cannot do anything about this is because it lacks
the detailed knowledge regarding which portions of memory are used for
what purpose. That information is normally discarded during compilation
(unless you compile with debug information). By the time you get to
running a binary executable, you're at a level of "code writes data",
with no details about which parts of memory belong to specific variables.

If the code segment was write protected and execute-only, and data
segments were not executable,

That will prevent code injection, limiting an attack to whatever is
code is already available in the process' address space.

and if there were separate data and return-address stack pointers,

That would eliminate the return address as a vector. There's still
function pointers; C++ uses these extensively (virtual methods), COM
even moreso (all COM methods are virtual).

And there's still the case of overwriting data which affects control flow
(the most extreme case is data which is "code" for a feature-rich
interpreter).

the OS *would* know when a process does something dangerous.

Only sometimes.

In any case, none of this deals with *preventing* buffer overflows, but
with mitigating the consequences.

.

Relevant Pages

  • Re: Possible buffer overflow vulnerability solution.
    ... with XP SP2 and Windows ... data is overwritten by a buffer overflow attack. ... Execution Prevention feature marks certain parts of memory as no execute. ...
    (microsoft.public.security)
  • Re: Possible buffer overflow vulnerability solution.
    ... Most buffer overflows DO occur by the means you say, ... > data then overwrites an area of memory that contains executable code. ... > next time Windows goes to execute that overwritten piece of code it ...
    (microsoft.public.security)
  • Possible buffer overflow vulnerability solution.
    ... buffer overflow exploits occur when more data is ... data then overwrites an area of memory that contains executable code. ... next time Windows goes to execute that overwritten piece of code it ...
    (microsoft.public.security)
  • Re: Handling memory inside kernel
    ... if (InputBufferLength < bytesToTansfer) { ... the buffer, which you could then have RtlCopyMemory to where ever, if you ... Don Burn (MVP, Windows DKD) ... I have allocated the memory on the function ...
    (microsoft.public.development.device.drivers)
  • Re: Handling memory inside kernel
    ... if (InputBufferLength < bytesToTansfer) { ... the buffer, which you could then have RtlCopyMemory to where ever, if you ... Don Burn (MVP, Windows DKD) ... I have allocated the memory on the function ...
    (microsoft.public.development.device.drivers)
Loading