Java and security

Ever increasing hard-drive capacity basically mean that one can keep a lot of old stuff around. While looking around, I found the files for old Java applets I wrote early in my PhD. I though it would be cool to be them into this blog. Except it would be pointless as Java is increasingly disabled in web-browsers, and given Oracle’s horrible track record with Java security, I would be hard pressed to tell people to activate it.

The big irony, of course, is that when it was launched back-then, Java was about solving the horrible security problems posed by insecure languages like C, I remember all the talk about the lack of pointers, the sandbox… I would find the irony more amusing had I not been paged twice this week because of a Java program crashing because of something that looks like a memory leak.

Java is not the only language plagued by security issues, Ruby also has its share of problems. In all cases, the issue is not in the language per se, but either in the runtime system or in naive idiosyncrasies of coders, we are not so far from using sprintf. In the end the sandbox for web-browsers has been implemented where it should: at the operating system level. I’m not saying that C/assembly is in any way better, this year’s CCC showed its share of low-level exploits, I found the presentation on hacking Cisco IP phones very interesting. Basically, implementing secure system call dispatching is hard, who would have known…

In my opinion security is not so much a language problem as a serialisation/validation issue. The fact that every language comes with a new way of serialising data, and that none of them let you the code define constraints on what field can legally contain what does not help. We moved from to , the first has provision for specifying constraints on the data, the latter does not…

2 thoughts on “Java and security”

  1. “In my opinion security is not so much a language problem as a serialisation/validation issue.” — YES!!

  2. I also think a major contributing factor to the lack of security these days is that coders aren’t willing to accept that software engineering is applied discrete math, and not artistry. Too many coders, even hard-core Apache coders that work until 3AM, are way to fu-fu about their work. They would much rather code everything, and I do mean _everything_ right down to sequential logic, in Node.js than accept the fact that if they just sat down and *thought* about what the heck they were trying to write in the first place, there might be an easier way to accomplish it with languages and tools already known.

    They don’t realize that they can rather trivially prove invariants about their code as long as they stick to a reasonable subset of their choice programming language (that’s 80% the value of formal methods right there), and in doing so, does not affect performance, significantly enhances reliability and trustworthiness of their code, provability is kept at human scales, AND can deliver code on time and under budget. I know this because I do this every day with Forth. Forth is a language with zero safety nets, so you *have* to do this, or your project goes down in fiery flames for intractable bugs.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: