It's Time to Abandon Insecure Languages

[Jack Lloyd]

On Fri, 19 Jul 2002, Matthew Byng-Maddick wrote:

> On Thu, Jul 18, 2002 at 01:08:55PM -0700, bear wrote:
> > Agreed.  And I particularly like Scheme.  However, it's also not
> > hard to compile your C code with bounds checking turned on if you're
> > willing to sacrifice maybe a few things you shouldn't be using anyay,
> > so it's pretty inexcusable IMO to still be having buffer overflows.
>
> Erm, what things do you think you can sacrifice? Pointer arithmetic,
> perhaps, except that it's a fairly fundamental part of C. The problems
> of buffer overflows are slightly screwy. Can you tell me, for example,
> what the length of s needs to be on
> a) a 32-bit machine
> b) a 64-bit machine
> and notice that most people don't even consider this.
>
>   sprintf(s,"%l",long_val);
>
> And, how big (on the same platforms) is:
>
>   sprintf(s,"%lf",double_val);
>
> You should also note that snprintf(3) is widely regarded as non-portable
> due to its non-existence on many platforms.
>
> Most code is susceptible to this kind of thing, because people don't
> necessarily know to look for it.

C++ gets this somewhat more right, it has a built-in string type that
handles allocation for you, so on and so forth. It's not perfect but it
does make a lot of things a lot safer (concatenation and string<->numerical
conversions in particular). Of course this depends on the C++ libraries
doing it right (IIRC just recently a buffer overflow was fixed in GCC's C++
library).

A language that seems applicable to this discussion is E
(http://www.erights.org). I haven't touched it but other people I work with
have, and we've been considering embedding it into a system being done
locally.

-Jack


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com