At 10:55 AM -0600 11/15/06, Wall, Kevin wrote: > 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 ?
> 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. But a cryptographic secret should not be in user-readable memory in the first place, due to the risk of a trojan horse. That belongs in OS memory dedicated to the user but protected from them (i.e., inner mode) and at that point the operating system can mark such memory as not being subject to dumping. The user might enter a password to _unlock_ that secret key, and some trojan horse (or wiretap) might intercept that password and use it in a malicious fashion, but the trojan horse cannot export the secret key to another machine. (By secret key, I mean the secret half of a public key pair.) > Overall, I find these types limitations with Java or C# more frustrating > than I do with the performance issues. A native compiler should have no problem calling any system service. It would seem your objection is really to the bytecode engine version of Java rather than to the language itself. -- Larry Kilgallen _______________________________________________ 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
