Insecure Java Code Snippets

[Kevin.Wall at qwest.com (Wall, Kevin)]

Larry Kilgallen wrote...
> So tell me what you think is easier in C/C++.

Well, just from a pure language POV, in comparing C++ with Java (sorry,
not qualified to comment on Ada), there is one advantage to C/C++ over
Java and that is in C++ I have a much higher level of confidence of
doing things to clean up something when and object is destroyed. In
C++, you can write a destructor to do this clean-up and you can predict
exactly when the DTOR will execute. In Java, it is not so simple, even if
all you want is to reclaim memory. You never really know when an object's
finalize() method will be called (or even if it ever will except at exit) You are
not supposed to rely on the timeliness of object finalization, nor are you
really supposed to rely on finalizers to really do anything except for release
memory.

So why is this important? It's important because sometimes correctness
and/or security depends on proper "clean-up". E.g., releasing a semaphore,
overwriting memory (say for passwords or crypto keys), etc.

Aside from that, the fact that Java doesn't allow you (native) access to
all system calls can make things much more difficult. E.g., no direct
access to fcntl(2) makes it impossible to use *nix mandatory file and/or
record locking unless resorting to JNI. Or the fact that (AFAIK) Java doesn't
support exclusive opens of a file or deal natively with sym links can cause
security issues in certain situations. Of course these things are not so
much the language per se as they are the supporting runtime environment
which Sun wanted to ensure was portable across all the OSes that they
support for Java. It's a trade-off and given their design goals, probably an
appropriate one, but it does make doing certain tasks a bit more difficult
to do securely. (Another example, Java supports nothing in its runtime
environment to prevent an object from being paged out to swap--something
that again would be desirable for things like crypto keys.)

-kevin
--
Kevin W. Wall   614.215.4788            Application Security Team / Qwest IT
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents."        -- Nathaniel Borenstein, co-creator of MIME