OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Bugtraq archives for 3rd quarter (Jul-Sep) 1998: Re: EMERGENCY: new remote root exploit in UW imapd

Re: EMERGENCY: new remote root exploit in UW imapd

Brett Lymn (blymnBAEA.COM.AU)
Mon, 20 Jul 1998 12:02:10 +0930

According to Craig Spannring:
>
>Strictly speaking, this is true.  However the defect goes far deeper
>than a simple coding error.
>

Assuming that the compiler not checking bounds on arrays is a defect
that is - a lot of people are, no doubt, manifestly unconvinced on
this point ;-)

>
>C should not be used for trusted programs.  The lack of true arrays
>with array bounds checking alone makes it too hazardous.

No, not bounds checking tainted data (i.e. data that comes from
sources other than your own code) is too hazardous.  Like it or not,
bounds checking arrays is an overhead.  If you have the compiler do it
then you incur that overhead on every array access.  If the programmer
does the bounds check then you can reduce the bounds checks to the
_appropriate_ places.  The art of good programming is making sure you
know the appropriate places.  You are also placing a heavy reliance
that the compiler & supporting libraries actually correctly do the
bounds check for you.  This may lead to a false sense of security, I
know that it can be argued that the compiler can be reviewed for such
problems but we are all familiar by now with how this does not
necessarily fix all the problems.

> How many
>buffer overflow attacks would we hear about if the trusted server
>programs were written using a language with bounds checking like
>Modula-2 or Ada?  Zero.
>

How many server programs are out there are actually written in Ada or
Modula-2?  Not that many I would estimate.  Even if they are out there
then, by your argument, they are still flawed because of the
underlying operating system.  There are very few OS's that are written
in Modula-2 or Ada, they do exist but they cannot be called anywhere
near widespread.

>The Internet is becoming a critical part of society.  Can we afford to
>rely on an inherently dangerous programing language?
>

Rather than blame the language perhaps we should look at the
programmer training.  Being a certified internet programmer (or
whatever you want to call the thing :-) to give assurance that the
programmer has been trained to program correctly - regardless of the
language.  Too many times the people cutting code are ones that have
started out ditzing with BASIC or whatever and then progressed to C.
They are self taught and have, more than likely, picked up many bad
habits that result in bad code.  Good programming takes vigilance and
experience - it should be taught.  Blaming the tool is not the answer,
the tool may help somewhat but in the end it is up to the programmer
not the tools they use.  You can do bad things (actually, worse
things because you need to make assumptions about the sizes of data
types) with Modula-2 to bypass all the bounds checking by casting
things to h*ll and back, I have done it in the past.  A sufficiently
determined programmer can write crap code despite the language.

>Sometime in the not to distant future there will be a major
>catastrophe related to insecure Internet software.  Perhaps a major
>bank will go broke, perhaps the stock market will be manipulated, I'm
>not sure about the specifics but it will happen.  There will be a
>congressional hearing and they will ask why such a dangerous language
>as C was choosen.  How will the industry answer that?
>

You have more confidence in the process than I.  More than likely you
will just get some poor programmer put in the spotlight looking like a
rabbit about to get shot.

>.  C will not be considered safe and using it will open
>you up to serious liability.
>

This I doubt - you may actually have more people looking at designing
software to 2167A (or similar).  Perhaps.  More than likely all that
will happen is that the fine print of the software license will get
finer and you will just have the liability worded away in the
software license which is basically all that happens now.

>You ask, "When will we learn?  When?".  The answer is, "Soon."
>

Not soon.  I doubt if you will budge millions of lemmings any time in
the near future.

--
Brett Lymn, Computer Systems Administrator, British Aerospace Australia
===============================================================================
  And the monks would cry unto them, "Keep the bloody noise down!"
  - Mort, Terry Pratchett.