You guys, that’s what segmentation was invented for, right ? Buffer
overflows cause protection faults. If people used the architecture in the
right way, it would be a lot harder to exploit this kind of problem: just
put the buffer inside a segment, and poof, it blows up if the app pisses
outside the urinal.
The point being, if the buffer and the user’s code and data are in separate
segments, and therefore in separate address spaces, it’s not that easy to
get a buffer overflow to damage the user’s code or data.
On another line, a technique such as what we use in BoundsChecker could be
useful: put some signature bytes before and after the actual buffer space,
and check those markers for integrity on a regular basis.
Alberto.
-----Original Message-----
From: Dan Partelly [mailto:xxxxx@rdsor.ro]
Sent: Friday, August 09, 2002 11:04 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Is it possible to prevent any .exe file from
getting executed?
> Good news is that this is the focus of our security research here at
> Florida Tech
Ok , thats very cool. Please explain those good news.
> performing such machine instructions.
What are you talking about ? Which is the extent your code can protect
against buffer overflows ? Do you protect against exec in heaps, or only in
stacks ? BO techniques spawns an extremly wide range of methods. Do you
ensure address space randomization in any way ? How do you protect against
perfectly legitimate ntdll.dll code , runed as a malicous intent after a
buffer overflow (return to libc style) ? Please , shed more light on this.
----- Original Message -----
From: “Jorge E. Coll”
To: “NT Developers Interest List”
Sent: Saturday, August 10, 2002 12:35 AM
Subject: [ntdev] Re: Is it possible to prevent any .exe file from getting
executed?
> While you may be able to block certain .exe’s from executing, you are
> still vulnerable to execution of what we call malicious mobile code.
> Even though code may be executed from an executable (*.exe), it does not
> have to originate from such. Think of an attacker being able to create
> a buffer-overrun and then executing his/her code on your machine. How
> could you protect against that?
>
> What we really need is a method for marking trusted / un-trusted code
> and a way of “monitoring” or “supervising” this un-trusted code. If the
> execution of any un-trusted code performs malicious events, we simply
> undo such actions.
>
> Good news is that this is the focus of our security research here at
> Florida Tech. We’ve developed methods for placing ourselves between the
> OS and the user process (both user-mode and kernel-mode) and we’ve even
> been able to intercept machine-level instructions and disallow a process
> of performing such machine instructions. By our methods of “sandboxing”
> the OS, we have been able to implement an undo engine which allows us to
> run un-trusted code and monitor its behavior. We’re still working on
> this as there’s much more work to be done on the behavioral aspect of
> it. Our site is currently under serious work but feel free to check us
> out at: http://se.fit.edu
>
> My two cents,
>
> Jorge E. Coll
> Florida Institute of Technology
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Peter Viscarola
> Sent: Friday, August 09, 2002 4:19 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: Is it possible to prevent any .exe file from
> getting executed?
>
> “Moreira, Alberto” wrote in message
> news:xxxxx@ntdev…
> >
> > What’s needed is an authorization mechanism that is attached to
> contexts,
> > not to specific files or pathnames. “No running certain .exe files
> from
> the
> > network, please”. “No executing anything from inside an unzip
> operation”.
> > “No executing certain files from inside .bat files”. “No running
> executables
> > by doubleclicking on some website links”.
> >
> > And so on, user- or admin-selectable. Can Windows do that ?
> >
>
> Absolutely! Windows doesn’t include any free software that does that…
> but
> it could certainly be written with the fundamental tools the operating
> system provides.
>
> Sounds like a the start of a business plan, Albereto! Hey, I know a
> company
> that can you a cool file system filter driver for ya…
>
> Peter
> OSR
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@fit.edu
> To unsubscribe send a blank email to %%email.unsub%%
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>
—
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to %%email.unsub%%
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.