Security

What Perfect Forward Secrecy means

| Immanuel Sims

Let’s say you had an encrypted conversation with Bob yesterday. Today Bob accidentally posts his secret key on the internet. You still want your conversation to be private, right? So what can you do? You can use a cryptographic protocol with perfect forward secrecy (PFS). That will protect you against similar blunders by your conversation partners and even your own blunders of this type. Sounds pretty desirable, right?

Since the Snowden leaks, we know for sure that a variety of state run intelligence services record your communication – some of them with the explicit intent to decrypt it later when possible. And with many protocols you just need to break one key to be able to decipher many messages. PFS also protects against that: you usually need to break every single message individually.

So both blunder, as well as outright malice, pose a sizeable threat, which therefore we need to consider when designing our threat models.

Continue reading →

WildFly 8-10 and JBoss EAP 7 verbose HTTP headers

| Immanuel Sims

As a developer I am really happy to have an easy way to determine which version of a software I’m running. But I do not like it if my software tells everyone its name and version, as this gives important fingerprinting information to possible attackers.

If you use WildFly versions 8 through 10 or JBoss EAP version 7 the default configuration includes some HTTP headers that are too verbose in my opinion. JBoss EAP 6 is not affected by the way. The headers you get look like this

Server: JBoss-EAP/7
X-Powered-By: Undertow/1

Getting rid of these headers is really easy. So I think the tiny effort to remove these headers should be put into any project even if the probability of getting attacked and the possible impact are really small.

To fix the problem let’s have a look at the default configuration in the standalone.xml:

Continue reading →

commons-fileupload 1.3.3 resolves deserialisation vulnerability CVE-2016-1000031

| Immanuel Sims

CVE-2016-1000031 is a vulnerabilty in the extremely widely used Apache Commons library commons-fileupload – you might not even know you’re having it on your class path. It has a very nasty Remote Code Execution vulnerability with easy to use exploits publicly available up to version 1.3.2. What makes it even worse is that you do not even need to use the library – you only need to have it on your class path and to deserialise some data. The data is the attack vector. You can find a good in detail explanation of the vulnerability here.

It did take a while but with version 1.3.3 this vulnerability is finally closed (by default).

There is some stuff that you should know about the fix though:

Continue reading →

Secure JSF Application – why you should always define a servlet mapping

| Heinz Wilming

If you deploy a JSF application in WildFly 8, you can omit to define the JSF serlvet mapping. In this case three default mappings will be active out of the box.

  • <context-root>/faces/*
  • <context-root>/*.jsf
  • <context-root>/*.faces

Tested on WildFly 8.0.0.CR1 and JBoss EAP 6.2.0.GA

This behavior is not mentioned in the JSF 2.1 spec. But it explicitly allows implementations to use proprietary means to invoke the JSF lifecycle.

In addition to FacesServlet, JSF implementations may support other ways to invoke the JavaServer Faces request processing lifecycle, but applications that rely on these mechanisms will not be portable.

This default mapping can be problematic as it provides several path to access resources within your web application. Especially if you use security constraints to protect parts of your application. For instance if you restrict access to <context-root>/secure/* using a security constraint in your web.xml, web resources can still be accessed via <context-root>/faces/.
Continue reading →