Re: IP Level Encryption (kind of long)
From: Robert Wessel (robertwessel2_at_yahoo.com)
Date: 12/18/03
- Next message: Chris Card: "Re: What makes NFS tick?"
- Previous message: Henrick Hellström: "Re: RSA vs DH"
- In reply to: David Wagner: "Re: IP Level Encryption (kind of long)"
- Next in thread: Henrick Hellström: "Re: IP Level Encryption"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: 17 Dec 2003 21:30:12 -0800
daw@taverner.cs.berkeley.edu (David Wagner) wrote in message news:<brpc0l$1mgt$5@agate.berkeley.edu>...
> Robert Wessel wrote:
> >"Skybuck Flying" <nospam@hotmail.com> wrote:
> >> Ofcourse a hacker could still try to overwrite other data which contains
> >> pointers to executable code like Henrick mentioned.
> >
> >Trying to secure all of this in hardware inevitably leads to the
> >re-re-re-re-re-re-reinvention of capabilities. And even then, only
> >the more extreme versions of capabilities can deal fully with the
> >pointer-to-function problem.
>
> I don't see why this requires capabilities. It seems to me that
> bounds-checking ought to be sufficient to deal with the kinds of
> failures that "Skybuck Flying" mentions. What am I missing?
Yes, the immediate issue Skybuck Flying raised needs little more than
simple bounds checking or a segmentation scheme. My point was that
this solves only a small subset of the potential problem scenarios.
As you start to try and fix all the other stuff in hardware, you tend
to reinvent capabilities.
> >Of course direct injection into memory is hardly the only way to
> >inject code into a system. For example, just rename an executable
> >image *.html, and point a link at it. It'll get downloaded and
> >probably stored in the browser's cache in a disk file. Now get
> >something to execute that file. Perhaps we could buffer overflow into
> >a string that is to be passed to system() - not a code pointer in
> >sight! OK, we can fix that by marking the cache directory as not
> >allowing code execution (a feature of most OS's). But now what about
> >scripts? As you said, "Ieewww... difficult problem !"
>
> That's one way to fix it. I believe another workable way to fix
> it would be to prevent the buffer overflow in the first place
> (e.g., using bounds checking).
The problem remains, how do you implement bounds checking in C? And
even if you do fix that (or switch to another language resistant to
buffer overflows), there's certainly no requirement that the injected
code be executed via a buffer overflow, that was only an example. All
you have to do is find *some* function on the target system that will
kick off the code. Perhaps a directory traversal vulnerability from
the \cgi directory via a web server on the same machine to kick off
the script or executable you convinced a browser to store in its cache
directory (IOW, ask for the URL
"http...\cgi\..\..\browsercache\nastyscript.pl").
- Next message: Chris Card: "Re: What makes NFS tick?"
- Previous message: Henrick Hellström: "Re: RSA vs DH"
- In reply to: David Wagner: "Re: IP Level Encryption (kind of long)"
- Next in thread: Henrick Hellström: "Re: IP Level Encryption"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
