Re: X68-64 buffer overflow exploits and the borrowed code chunks exploitation technique
tomstdenis_at_gmail.com
Date: 10/08/05
- Next message: Anne & Lynn Wheeler: "Re: X68-64 buffer overflow exploits and the borrowed code chunks exploitation technique"
- Previous message: tomstdenis_at_gmail.com: "Re: X68-64 buffer overflow exploits and the borrowed code chunks exploitation technique"
- In reply to: Anne & Lynn Wheeler: "Re: X68-64 buffer overflow exploits and the borrowed code chunks exploitation technique"
- Next in thread: Anne & Lynn Wheeler: "Re: X68-64 buffer overflow exploits and the borrowed code chunks exploitation technique"
- Reply: Anne & Lynn Wheeler: "Re: X68-64 buffer overflow exploits and the borrowed code chunks exploitation technique"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: 7 Oct 2005 15:28:15 -0700
Anne & Lynn Wheeler wrote:
> tomstdenis@gmail.com writes:
> > Such a language exists?
> >
> > Tom
>
> note that this periodically gets repeated ... some collected posts
It gets repeated because nobody wants to listen to the actual
information made available.
Sure langs like Java [JVM written in C] or Perl [written in C] or PHP
[written in C] could be resistant to some attacks that C is not...
HOWEVER, you can still write bad programs [re: insecure] with these
supposedly secure languages.
So the question is: if Java [for instance] provides "a bit more"
resistance why not just wholesale abandon C and use it instead?
The answer is if you're writing something that has to actually run
anywhere [and not just "anywhere there is a JVM"] then you want to know
C.
> however there are languages and environments where the frequency of
> such things happening are drastically smaller (possibly two orders of
> magnitude smaller) for this class of mistakes.
I'd like to point out there is an order of magnitude fewer servers in
Java or Perl or PHP then C.
> i was involved in a tcp/ip stack implementation in the 80s that was
> done in pascal ... and was not known to have any of the overflow
> vulnerabilities that seem to be so common. in part, because a lot of
> the buffer-to-buffer type operations didn't depend on the programmer
> having to manage the bounds of the target ... it was built into the
> operations. as a result, there were significantly fewer situations
> where the opportunity for making target length related mistakes.
How hard is it to do checks as you decode fields? e.g. you know your
input is "inlen" bytes and you just decoded a field length 'k'. Check
if k+current_read>inlen ... not hard.
If you write, oh, I don't know, modular code with consistent style and
design these "really annoying checks" not only become trivial but also
routine.
I don't know where these people get the idea that "all programs should
be trivial". Granted I don't do things the hard way but there are
times where you have to actually "do work" to get things done.
Sure you can sit on your ass and wait for someone to write a Java class
but all you're doing is waiting for someone else to write/test the
class you need.
Tom
- Next message: Anne & Lynn Wheeler: "Re: X68-64 buffer overflow exploits and the borrowed code chunks exploitation technique"
- Previous message: tomstdenis_at_gmail.com: "Re: X68-64 buffer overflow exploits and the borrowed code chunks exploitation technique"
- In reply to: Anne & Lynn Wheeler: "Re: X68-64 buffer overflow exploits and the borrowed code chunks exploitation technique"
- Next in thread: Anne & Lynn Wheeler: "Re: X68-64 buffer overflow exploits and the borrowed code chunks exploitation technique"
- Reply: Anne & Lynn Wheeler: "Re: X68-64 buffer overflow exploits and the borrowed code chunks exploitation technique"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
