Eclipse Java

Remove Checkstyle warnings for certain classes

Checkstyle warnings for generated or automatically filled classes like in Eclipse RCP can be annoying. But even without the .checkstyle file under version control, it is possible to deactivate Checkstyle warnings for selected files.

First you have to add the SuppressionFilter module to your Checkstyle configuration file:

<module name="SuppressionFilter">
 <property name="file" value="${samedir}suppressions.xml"/>

The path entered to suppressions.xml must be absolute, ${samedir} takes care of that.

The suppressions.xml file contains a simple list of suppress elements, where a . as checks-attribute property represents all checks (the attribute value is a regular expression). The other possibility is to deactivate only selected checks by inserting a module name as configured in the Checkstyle configuration.

<?xml version="1.0"?>
<!DOCTYPE suppressions PUBLIC "-//Puppy Crawl//DTD Suppressions 1.1//EN" "">
 <suppress checks="." files=""/>

Events Secure Development

Java Security Myths session at DOAG 2013

DOAG SpeakerI’ll be speaking about Java Security Myths at the DOAG 2013 conference in Nürnberg. My (German) session is on November 21st at 10 a.m.


A little bit more security for Java in the browser

Oracle just released Java 7 update 21, containing once more many security fixes (install it right away). And some changes for applet usage und handling. First of all, the preference dialog does not contain the low security setting any more. Which forces more user interaction when launching unsigned applets. Unsigned applets therefore require at least some interaction now; they are not launched automatically any more. A future Java update (probably the next update in July) will prevent you from running unsigned applets at all. And there will be a blacklist which will protect you from running applets signed with an invalid or revoked certificate.

For sure this will have a positive impact on Java browser security, but it’s not a big catch. This totally relies on certificate authorities and that they carefully check people buying certificates. And we all know how well that worked out in the past many, many times. It’s just too easy to get valid certificates. And there are no restrictions left when running signed applets.
Yeah, now we ‘know’ who bought the certificate and probably signed the malicious applet and can trace it back. Up to the point where we figure out a faked id was used to buy the certificate. This is not helpful at all. Oracle’s reaction to certificate fraud is to add such an invalid certificate to the frequently(?!) updated JRE certificate blacklist and prevent the JRE from further applet execution. This might work in 80% of the time. The other 20% will receive this update too late. In my eyes this is not a real solution, just another workaround to avoid killing the whole Java applet support at all.

Of course it is not Oracle’s fault that it is that easy to get a valid certificate with a fake id or no check at all. But fixing one broken system with another broken system is simply not going to work. And the loser is Java.


It’s a hattrick

Just received the great news that my session on Java Security Myths has been accepted for the upcoming Java Forum Stuttgart 2013. This is the third time in a row for me to speak at JFS after Git in 2011 and Secure Software Development in 2012. Looking forward to seeing you in Stuttgart on July 4th 2013.


Java in the browser is dead

So its certificates now. Looks like Java applets don‘t care about certificate revocation lists at all. Signed applets gain full access to the system. An invalid certificate should prevent that. Which means a certificate revocation list is kind of important. But no, let’s forget about that check. No need to hack the sandbox this time (which is easy anyway, see the last couple of Java updates).

This is another huge security failure in Java applet ‘security’ again. One in a long way. And not the last one. In fact there are still some known vulnerabilities even in the latest Java version.

The latest series of security problems caused a lot of damage for the whole Java platform and ecosystem. As a Java developer I can (and do) only advise everybody to uninstall Java or at least to deactivate Java browser support. Like a lot of people do. But what’s Oracle’s reaction? By shipping one critical update after the other. Faster than ever. But that won’t change much, the next critical security hole is just around the corner. Java in the browser is insecure and will remain so. And Java in the browser is that. Oracle just won’t admit it.

The problem with that is: Java on the client will be dead next. Normal users cannot distinguish between Java browser applications and rich clients (kind of our fault, since we told everybody for years now to ignore that border). Server side Java will not die that easily (good!), but the last couple of months caused a lot of damage there too. It became much harder to argue for a Java web application instead of .net for example. Not that other frameworks don’t have security issues too. But all people hear at the moment on a certain (management) level is that Java is insecure and needs security fixes every couple of days. How would you react?

This will become even harder in the future if Oracle continues like that. The only solution in my eyes is to remove Java browser support right now. Get rid of this totally outdated and widely unused peace of technology. Restore Java’s good reputation before it is too late.

Secure Development

OWASP Top 10 2013 release candidate published

The first release candidate of the new OWASP Top 10 2013 was published a couple of days ago (PDF). And the top 10 changed quite a bit (see the project wiki):

  • A1 Injection
  • A2 Broken Authentication and Session Management (was formerly A3)
  • A3 Cross-Site Scripting (XSS) (was formerly A2)
  • A4 Insecure Direct Object References
  • A5 Security Misconfiguration (was formerly A6)
  • A6 Sensitive Data Exposure (merged from former A7 Insecure Cryptographic Storage and former A9 Insufficient Transport Layer Protection)
  • A7 Missing Function Level Access Control (renamed/broadened from former A8 Failure to Restrict URL Access)
  • A8 Cross-Site Request Forgery (CSRF) (was formerly A5)
  • A9 Using Known Vulnerable Components (new but was part of former A6 – Security Misconfiguration)
  • A10 Unvalidated Redirects and Forwards

Some changes are a little bit surprising in my eyes at first. Definitively not that injections are still number 1. Guess some things never change. But I think the drop of XSS from 2 to 3 and CSRF from 5 to 8 does not reflect reality. Sure, there is little more awareness to these problems (only a little), and some Java frameworks offer (some, but getting better) out-of-the-box-protection. But these issues are still tough to solve and are still dangerous. And they are a good eye-catcher and easy to talk about. Hopefully that does not prevent developers to think about it during web application development. Not that the other items are unimportant, however I can’t fully agree with the order.

But whatever is your motivation for secure development (in case you simply need another one besides, well, security), don‘t take the OWASP top 10 positions too seriously. The issue is important, not the current position. OWASP top 10 issue 11 (whatever dropped out the list) may be your issue number 1. And even a controversial list makes developers talk about security, which is the best thing that could happen to us.

The OWASP Top 10 2013 final version should be available in May 2013.


JCrypTool Tycho builds finally working

The last couple of days brought a lot of updates for the Eclipse Tycho build in JCrypTool. And I‘m happy to say that everything is working now (except some minor issues). Since JCrypTool is a rather complex RCP (about 45 core plug-ins/ features, about 75 crypto plug-ins/ features) the setup required quite some time and restructuring. The crucial factor was to create and reorganize three main projects: org.jcryptool.releng is our new main project containing the parent pom used to start the build process. org.jcryptool.product contains the product configuration as well as additional product config files and our target platform configuration. org.jcryptool.repository contains the p2 update site and (important) the categories for this update site. Separating this three project more or less did the main trick. Have a look at these pom files to get started.

As I‘ve said before, some stuff is still missing. For one I‘m looking for a way to update certain property-files with the current release date before the build. And I‘m a little bit unhappy about the filenames of the generated artifacts. In order to get useful filenames I‘m using maven-antrun-plugin for renaming them as the final step. I would expect that there is a way to configure Tycho to do this, but couldn‘t figure it out. The final item on my list is the target platform. At the moment we are using the Eclipse repository for Indigo and the Babel Indigo repository. This is painfully slow. However, setting up a maven mirror did only work for Babel, not for Eclipse Indigo. The problem here are some unresolved dependencies.

Eclipse Tycho is a nice build tool, but it is (very) hard to set up. Depending on the complexity of your RCP it takes a long while to get everything working. Starting with a simple RCP did not work out for me, the problems came along with JCrypTool and its complexity. What has helped a lot was the separation into the three projects I‘ve mentioned above. Better do that from the beginning. And keep your plug-in dependencies clean.

Solved the first open task to integrate the build number in certain property files with the help of a good blog post.


Making Java secure again

The recent total failure of Java security is neither the first one, nor will it be the last one. Java in the browser (in the form of Java applets) is not secure and will never be secure. Oracle can provide all the security patches they want, the next major security breach is just around the corner.

This is comparable with Microsoft Windows security a couple of years ago. Year after year they tried to fix it and ran from bugfix to bugfix before noticing it will not change too much and that a complete redesign of their operating system is required. In case of Java the only solution (in my eyes) is to remove Java browser support with the next major release Java 8. This feature is not widely used any more, applets are plain old technology. Oracle should announce the stop of support right now. Don’t tell people to deactivate it, this is not a solution. Don’t even ship it. Users still requiring Java in the browser can use Java 7 in the transition period. This should provide enough time for all companies and all products to switch from unsecure Java applets to much safer Java web applications. And companies still using Java applets should ask themselves, why they force their users to rely on an unsafe technology.

Oracle keeps telling (e.g. in the JRE installation dialog) us that 3 billion devices run Java. This number will go down rapidly with every new major security problem. The security problems of one little part of the platform will have a negative influence on the rest of the platform. Word will spread that Java is insecure. This makes the usage of Java in any project harder than necessary. Server side Java is safe, Java desktop applications are safe, Java embedded is safe (in the usual dimensions). But it’s hard to argue about Java safety with everybody hearing about Java security failures in mainstream news. Normal users do not and cannot differentiate between web and desktop application security as we developers do. For a normal user Java is failing. This will be a huge problem in the future.

And finally, removing Java browser support will give more time for all the great Oracle Java employees on moving the platform forward. The rest of the Java platform would surely benefit from that.


Java 7 update 11 available, addressing the latest major security flaw

So, Oracle released Java 7 update 11 today, addressing the latest major security flaw with Java applets. Guess we are safe now for about a week. Of course I strongly recommend installing the new release as quickly as possible. But keep Java disabled in your browser! In case you do need a Java applet I’ll recommend to only activate Java on demand. Java in the browser (I’m talking about Java applets only) is outdated technology, and it is totally unsafe. And it will remain unsafe, no matter how many security patches will be provided by Oracle. The next security flaw is just around the corner. It is time to get rid of Java browser support; focus on server side Java, Java desktop applications as well as the mobile world. Java rocks, but it definitively sucks as a safe browser extension.

Eclipse JCrypTool

Solved the Eclipse RCP export failure on OS X

After a lot of trial and error, I’ve solved the Eclipse RCP export failure on OS X. The solution was to force Eclipse to use Java 1.6 and not the default 1.7. Simply add the following line to your eclipse.ini: