Larry Kilgallen wrote:
> At 8:18 PM -0600 11/14/06, Wall, Kevin wrote:
>
> > That makes a Java inappropriate for a lot of
> > system-level programming tasks. Simple example: There's no
> > way in pure Java that I can lock a process in memory. Wrt this
> > list, that has a lot of security ramifications especially on
> > shared processors. Sure makes hiding secrets a lot harder.
>
> Please explain that issue.
>
> Is there some multiuser operating system that does not clear
> memory before retasking it for another process ?
By shared processors, I didn't mean multi-CPU systems, but simple
computers used by multiple users. Sorry for the possible confusion.
I wasn't referring to the OS not clearing memory between use by
different processes. Instead consider a case where there's a secret
such as an encryption key, password, etc. in a chunk of memory that
has been paged out to a swap device (*nix) or pagefile.sys (Windows).
The process them terminates abnormally because of a signal, abrupt
power outage, etc. From a security POV, this is a bad thing since
now your secret is somewhere on the hard drive. If your computer
is physically secure and the OS is probably secured, this is a
relatively low risk, but it still may not be acceptable. In the
first case, where your Java process might abnormally terminated
via a signal, you may even end up with a process [core] dump.
In C/C++, I'd use something like mlock(2) or perhaps memcntl(2) and
lock the secret in physical memory. But there's no way to do this
using _pure_ Java.
Another example, perhaps easier to grasp and still security related.
Say you have a regular "console" application (i.e., doesn't bring up
it's own window; e.g., consider Windows console programs). Your
application wants to _prompt_ the user for a password. You would
like to disable echoing of the password to the console window.
In Java, you can do this if you use something like Swing or AWT,
etc., but there's no portable way that I've found using pure Java.
(Note: kludges such as continously overwriting each character as
it's input isn't secure. Consider case where user is running 'script'
or has xterm logging enabled, etc. Also, IMHO, calling an external
program, such as stty, from a Java program in order to disable and
re-enable character echo is also a kludge.)
In C/C++ or other language where I can call system calls directly,
this is easy to do (though not necessarily portable across different
OSes) via appropriate ioctl(2) call or various other means. (E.g., see
termio(7) for *nix systems.)
Overall, I find these types limitations with Java or C# more frustrating
than I do with the performance issues. If the performance issue is that
bad, it's usually my algorithm or data structures that need the tuning.
If all you need is to run machine code to get bettere performance,
then compile your Java with gjc or TowerJ or something similar. (Not
sure what options exist for C#.)
-kevin
---
Kevin W. Wall Qwest Information Technology, Inc.
[EMAIL PROTECTED] Phone: 614.215.4788
"It is practically impossible to teach good programming to students
that have had a prior exposure to BASIC: as potential programmers
they are mentally mutilated beyond hope of regeneration"
- Edsger Dijkstra, How do we tell truths that matter?
http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html
This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful. If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.
_______________________________________________
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
