Security-oriented languages (was: Privilege-escalation attacks)

From: David Hopwood (david.hopwood@zetnet.co.uk)
Date: 08/29/02 

Date: Thu, 29 Aug 2002 00:55:49 +0000
From: David Hopwood <david.hopwood@zetnet.co.uk>

-----BEGIN PGP SIGNED MESSAGE-----

Edward Elliott wrote:
> David Hopwood wrote:
> > Barry Margolin wrote:
> >> Edward Elliott <nobody@127.0.0.1> wrote:
> >> >Another good tactic. I see two ways to go about this. One is to
> >> >design new languages and libraries with security in mind.
> >>
> >> Remember when Java was supposed to be that language? :(
> >
> > Java is one of those languages. Don't confuse any problems that apply
> > only to running hostile code using ClassLoaders, with the properties
> > of Java that help in writing secure applications.
>
> If you're talking about avoiding buffer overflows, just about any
> language with bounds checking should fit the bill.

Not quite. In addition to bounds checking, I'd consider strict runtime
type safety to be absolutely necessary (assuming the language has references,
this requires GC, and atomic accesses for reference types). To the extent
that the language has a static type system, it should be loophole-free.
Support for exceptions is also a high priority. Ideally there should be no
possibility of undefined behaviour from any program run by a correct
implementation of the language, except in foreign language interfaces or
where the source explicitly declares the use of an "unsafe" feature.
(Even in those cases there should be well-documented rules that if followed
will maintain defined behaviour.)

Certainly there are quite a few other languages that meet or almost meet
these criteria, though - for example Eiffel, Sather, Ada83/95 (using GC),
Beta, Smalltalk, Cecil, Scheme, Haskell, Clean, etc.

> I don't see how Java has any special protection against race conditions
> (synchronized code helps protect what's in the app, but only if you use it
> properly.

Of course synchronization has to be used properly. What magic fairy dust
could a language apply to protect multithreaded code that doesn't use
synchronization properly (assuming it supports true concurrency and not
just the equivalent of coroutines)? IMHO the choice of reentrant lexically-
scoped monitors as a synchronization primitive works quite well in an
object-oriented language.

In any case, taking into account the changes that have been proposed in the
memory model JSR, the Java and JVM specs make a more serious attempt to
define the semantics of threading (albeit informally), than any other
language specification I've seen outside of pure research projects.

> AFAIK, external resources like files aren't protected from race conditions
> at all).

That's an OS-related problem. Don't expect a programming language to fix it.

> I see Java as a step above C and possibly C++ (depending on how educated
> your programmers are on security issues), but no better than any other
> language with bounds checking and without raw pointers. Can anyone make
> a good case that Java is more suitable for writing secure apps (not
> "safe" apps, i.e. sandboxed code) than another language with these
> features?

I wasn't trying to make that case. The distinction is between
{Java, Eiffel, Smalltalk, Scheme, ...} and {C, C++, Objective C, ...}.
I think any of the former group are fine choices for writing security-
critical application code (including many of the application-level parts
of an operating system), but the latter are not.

- --
David Hopwood <david.hopwood@zetnet.co.uk>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBPW1wvzkCAxeYt5gVAQGfNAf/ZPNIt4qIaF1gnXvsi1k5Vxi553/kZGlt
XwWagFe0GTe94hgl2Xe/o5s2ZPGf9PLfJaCrjt3LomksKBKgaZTMRmz1eznEsafq
GvG7A/z8vLmdMDmVd/aWYKvQRT4k+uPrBBbaKUal3NU5P8jonggmg6UcbnJ/GYki
CtDKptxXpxN+T8acgh9ss5i1SHT3RFesb1q22IZXayft+oS64zzhYGhqcNWu2T+e
Cm+CaUCQnWcG5/vHA6flRxbvhZjIBdiulh+7fFhHRNzVBfg3nZteEIxBk+blVPPW
GK5XgQ1MViB70lqQiGThffGXpIxad/bUjPOkjwhxFXsmc5ai0gxL/Q==
=g0h+
-----END PGP SIGNATURE-----

Relevant Pages

  • Re: Security-oriented languages (was: Privilege-escalation attacks)
    ... > Of course synchronization has to be used properly. ... > dust could a language apply to protect multithreaded code that doesn't ... be assured by the language. ... >> anyone make a good case that Java is more suitable for writing secure ...
    (comp.security.misc)
  • Re: Security-oriented languages (was: Privilege-escalation attacks)
    ... > Of course synchronization has to be used properly. ... > dust could a language apply to protect multithreaded code that doesn't ... be assured by the language. ... >> anyone make a good case that Java is more suitable for writing secure ...
    (comp.os.ms-windows.nt.admin.security)
  • Re: Comparing Lisp conditions to Java Exceptions
    ... All the ISO standards in the world will not make the world ... Nothing keeps you from annotating your program with exceptions based on what ... language should adhere to your theory. ... Curiously, although you don't say it, Java has the opposite problem. ...
    (comp.lang.lisp)
  • Re: casts
    ... This is why most shit programmers refuse to learn languages including ... C Sharp and Java. ... compiler in a later edition of Visual Basic, ... language for processing data. ...
    (comp.lang.c)
  • Re: C, really portable?
    ... > Wait, is Java a modern language superior to C, or is it still ... It is a much better OO language than C++, ... It depends what you are doing, Java aims for rigorous portability - the same ... regardless of platform. ...
    (comp.lang.c)
Quantcast