Re: "Perfect" or "Provable" security both crypto and non-crypto?

From: Anne & Lynn Wheeler (lynn_at_garlic.com)
Date: 09/17/04


Date: Fri, 17 Sep 2004 11:05:17 -0600


"Roger Schlafly" <rogersc1@mindspring.com> writes:
> I don't know what Doug had in mind, but there are lots of ways
> that buffer overruns can occur in any language.
>
> Consider a program that reads from a data stream (such as a
> file or internet socket), and writes to another stream.
> It reads a particular data field, for which the specs say
> that it will be null-terminated and less than 64 bytes long.
> The program reads the data into a larger data structure,
> and ignores the 64-byte limit because it assumes that the
> null terminator will be there. Then all sorts of bad things
> can happen.
>
> Such buffer overflow bugs can occur in Java or Perl or
> anything else, and such bugs are common. Those languages
> are a lot safer than C because a simple string copy is not
> going to blow the stack, but there can be other buffer overrun
> bugs.

but assertion is that c programming conventions can increase the
occurance of such overrun bugs by a factor of one to two orders of
magnitude.

the multics (written in pli) study claims that there was never such a
problem in multics system.

previous post in thread ...
http://www.garlic.com/~lynn/2004l.html#21 "Perfect" or "Provable" security both crypto and non-crypto?

part of the issue is security proportional to risk .... if the risk is
one hundreds times greater ... then people might be included to pay
more attention to it than other security risks that might have
significantly lower rate of occurance.

some recent threads in other n.g. discussing relation between programming
language and predisposition to buffer over run/flows:
http://www.garlic.com/~lynn/2004j.html#37 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004j.html#38 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004j.html#58 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004k.html#2 Linguistic Determinism
http://www.garlic.com/~lynn/2004k.html#5 Losing colonies
http://www.garlic.com/~lynn/2004k.html#6 Losing colonies
http://www.garlic.com/~lynn/2004k.html#20 Vintage computers are better than modern crap !

-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/


Relevant Pages

  • Re: perfomance vs. key size
    ... > There are buffer overruns even in various versions of MS CryptoAPI ... > exploitable bugs and increases the probability that any bugs are ... http://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation ...
    (sci.crypt)
  • Re: [Lit.] Buffer overruns
    ... I thought we wanted, ideally, a program with no bugs. ... >>with eliminating buffer overruns. ... > would be pointless if programmers would only follow your discipline. ... > Is the same true when you restrict attention to exploitable security ...
    (sci.crypt)
  • Re: Linux Xorg Is Riddled With Security Bugs. Its a Hackers Dream!
    ... Nate Bananarama Latwanda III Jr. ... The bugs are scattered across the whole ... > include endless loops, buffer overruns, buffer underruns, code ... > applications that use libXpm to process data from untrusted sources. ...
    (alt.os.linux.suse)
  • Re: Linux Xorg Is Riddled With Security Bugs. Its a Hackers Dream!
    ... Nate Bananarama Latwanda III Jr. ... The bugs are scattered across the whole ... > include endless loops, buffer overruns, buffer underruns, code ... > applications that use libXpm to process data from untrusted sources. ...
    (alt.os.linux)
  • Re: [Lit.] Buffer overruns
    ... these buffer overruns don't appear magically from nowhere. ... I'm most concerned about inadvertent bugs (buffer overruns that were ... the N-person code review stage. ... Code reviews are good, but I don't know ...
    (sci.crypt)