RobertJasiek wrote:
For a statically compiled application and for a buffer to overflow, there must be a reason: division by zero, missing garbage colletion or interpretation of unchecked input of network data or GUI entered data. The programmer need not be a security expert to avoid such, but he just needs discipline: check for unequal to zero before dividing, clean the dynamic heap data structures, check input data before processing them.
Or missing/buggy array bounds check. Or something wrong with your recursive function. Or a subtle race condition in multi-threaded code. Or any of these not in your code, but in one of the libraries you use, including the operating system. I could continue that list...
It takes a lot more that "just discipline" to avoid these kinds of errors with "native" languages like C, and that's even assuming that you know about all the potential problems. Actually, the fact alone that you are not aware of all these subtle things shows that it's not that easy to write a secure application. It's just not possible to think of every existing attack vector out there and actively protect against it.
The advantage of using a "safe" language (like Java) is that you don't have to worry about a huge percentage of these things, because the worst that can happen is that your application crashes, and the attacker is never going to be able to insert malicious code through a bug in the application.
RobertJasiek wrote:
A java application can have more than one attack vector. In particular, the application's JAR file can be bad or even hacked and contain malicious code. Published checksums of distributed JAR files and manual installation could reduce the problem. AFAIK, so far programmers of go software even fail to publish checksums.
Replace every instance of JAR file with EXE file, and you have an even worse problem. That's actually the point of the whole fuss: With Java, you have security measures in place against masicious code. They are just not perfect, there are apparently some security holes. With EXE files and native applications, you have no security at all, if you don't trust the file and its author, you can't use it, period. On the other hand, it takes a little bit more than "just" malicious code in a JAR file to break out of the Java sandbox. That's why people (and sadly also browsers) tend to blindly trust in Java to protect them, and it's really bad when suddenly it's discovered that Java isn't perfect. But there is no such thing as bug-free software.
And while we're at it, I actually have no idea why until recently browsers just executed plugin content (including Java) without asking the user. You'd think people have learned something from ActiveX plugins
. And even worse: At least on Firefox, there is an exception for Flash, so I expect all the security problems to just shift to a different plugin, now that the default is click-to-start for everything else. But maybe not, because people just tend to click on Ok anyway
.
Executing code from an unknown source just isn't a good idea, ever, regardless of programming language
.
RobertJasiek wrote:
The toughest attack vector might be hijacking of a running application instance.
Actually, for C programs, that's the most common attack vector. For Java, it's almost non-existant.
As a practical example, all things being equal, just assume there is an alternative KGS client written also by wms, with exactly the same feature set, but written in C++ instead of Java. Which one would you use?
I would definitely use the Java client, because while I'm pretty sure I can trust wms, I'm also pretty sure there are security relevant bugs in the code. There always are, as soon as the application uses network connections. But I'm also pretty sure that the Java VM protects me from most of them by just crashing the application in the worst case, instead of allowing an attacker to capture my computer.
On the other hand, if someone I don't trust sends me a program, I don't think it's a good idea to start it, not even if its written in Java