Insecure Libraries

Sonatype and Aspect Securitiy recently published a study titled “The Unfortunate Reality of Insecure Libraries” (registration required). The bottom line is that 80% of the code in today’s applications comes from libraries and frameworks and that the risk of vulnerabilities in these components is widely neglected. Sonatype and Aspect Security have analyzed the downloads from Maven Central and found that 26% of the downloaded libraries have known vulnerabilities.

Of course this is marketing material but nevertheless it contains a lot of truth. Many organizations lack a process to ensure the libraries they are using in their applications are up to date. The larger an organization is the higher the probability that they prefer not to update their dependencies because they fear to break something. Never touch a running system – even if it is insecure.

You can argue that the metrics they use are inaccurate as a vulnerability in a library that is used in an application does not imply that the application itself is vulnerable. However if the application is not affected by the vulnerability of a dependant library this is more often by coincidence than by analysis and informed decision.

For applications that we are building for our customers we have a few rules in place that lower the risks involved:

  • We prefer proven frameworks and libraries with a good security track
  • We check the general code quality of frameworks and libraries we use before we include them
  • Each iteration starts with updating the dependencies of our applications to their latest stable version

While this works well for applications while they are built it does not help for the phase where no active development takes place. It also doesn’t help with security issues that are discovered and need an immediate fix for the release currently deployed to production.

Therefore we offer support contracts for our applications that cover the latest production release in supported environments. To minimize cost we do not support older versions or milestone, beta and candidate releases.

For those versions we provide our customers with security fixes for vulnerabilities found in one of the supported products or the libraries used in one of these products. This of course includes monitoring the libraries and frameworks we use for reported vulnerabilities and security issues.

We also encourage our customers to plan for maintenence releases at least every six months to keep the dependencies up to date even if there are no new features to be included.

Vulnerability in ApacheDS 1.5

Apache Directory Server (ApacheDS) is an LDAP server implemented in Java from the Apache Software Foundation.

The server supports a number of password hash functions including MD5, SHA, SMD5 and SSHA so that the clear text password used for authentication is not stored on the server and an attacker who gains access to the data can not use it for authentication unless he breaks the hash.

Password checks are implemented in the class SimpleAuthenticator that includes the following code:

// Get the stored password, either from cache or from backend
byte[] storedPassword = principal.getUserPassword();

// Short circuit for PLAIN TEXT passwords : we compare the byte array directly
// Are the passwords equal ?
if ( Arrays.equals( credentials, storedPassword ) )
    if ( IS_DEBUG )
        LOG.debug( "{} Authenticated", opContext.getDn() );

    return principal;

The provided credentials are compared to the stored password which can either be a plain password or the hash of a password. This causes ApacheDS to allow users to authenticate either with the password or the corresponding hash. So authentication of a user with the password abc which is stored as the salted SHA1 hash {SSHA}lIifvzM278asTV8NtjfO3EV3z4caaC5uJPouWw== will succeed if either the original password or the hash is provided.

Both calls will succeed equally:

ldapsearch -h localhost -p 10389 -D uid=admin,ou=system -x -w 'abc'
ldapsearch -h localhost -p 10389 -D uid=admin,ou=system -x \
  -w '{SSHA}lIifvzM278asTV8NtjfO3EV3z4caaC5uJPouWw=='

An attacker who gains access to the stored hash will thus be able to successfully authenticate as any user without having to know the password.

It seems all versions of ApacheDS 1.5.x including 1.5.7 are vulnerable. The new 2.0 branch does not seem vulnerable.

I’ve notified the Apache Security Team on 2012-03-12 and informed them on 2012-03-15 that I will publish this blog entry on 2012-03-19 after they remained silent for three days.

Emmanuel Lécharny finally replied that he does not consider 1.5.7 stable and that

People using the server *must* use 2.0.0-Mx versions, even if this version is not stabilized yet.

The reason they still link to the vulnerable 1.5.7 version in their “Latest Downloads” section without a word on the security issue is

Pure laziness… Sadly, we are knees deep into coding, and we have neglected the web site and the doco :/

Seems priorities are more on publishing good news.

Update 2012-03-27: Now more than two weeks after the notification they had plenty of time writing emails explaining why this isn’t a problem but apparently no time to remove the link to the vulnerable version from the Latest Downloads section.

Malicious Toolbars

We recently received a bug report for a web application. The user was unable to use the application due to JavaScript errors that showed up when loading the main page and the screenshot we received showed JavaScript code in a place where the application usually displays a list of informational messages:

Our first attempt was to google for the code snippet to see if it was mentioned elsewhere. It showed up on a few sites, in some forums but nothing really interesting.

The screenshot included an additional detail that caught our attention. A few toolbars were installed in Internet Explorer including the Pdfforge Toolbar:

This toolbar comes with PDFCreater and Wikipedia has some details on it:

The installation package includes a closed-source browser toolbar that is considered by many users to be malicious software (see below). Although technically an optional component, the opt-out procedure is a multi-step process which is considered by many to be intentionally confusing.

The toolbar injects additional JavaScript code into the browser to track its users, report visited sites and show ads.

It turned out that the toolbar had added an indexOf() function to Array.prototype:

Array.prototype.indexOf=function(a){if(this===void 0||this===null)
throw new TypeError;var b=Object(this),c=b.length>>>0;
if(c===0)return-1;var d=0,e=d;arguments.length>0&&(
var f=d>=0?d:Math.max(c-Math.abs(d),0);for(;f<c;f++)
if(f in b&&b[f]===a)return f;return-1}

This seems to be a workaround for older versions of Internet Explorer that don’t support the indexOf() function natively. To understand how the code ended up in the info messages field here is how the application iterated over the array of messages to display:

for (var i in messages) {
  // adds an element for each key in the messages object
  // including messages["indexOf"]

The correct way to iterate over an array is however

for (var i = 0; i < messages.length; i++) {
  // adds elements only for the values in the array

Yet another case where the two loops show different results is the following:

var a = [];
a[5] = 5;

for (var i=0; i<a.length; i++) {
    // iterates over numeric indexes from 0 to 5

compared to

for (var key in a) {
    // shows only the index of "5" and ignores 0 to 4

What can we learn from this?

  • Do not use with arrays
  • Do not modify built-in datatypes as others may depend on them
  • Be careful what you install on your computer

Spring Framework Security Vulnerability Part 2

I’ve already talked about CVE-2010-1622 and what SpringSource could have done better when dealing with this security issue.
Today I want to focus on what you as a developer or system administrator can learn from the bug.

What can developers learn from CVE-2010-1622?

The exploit requires manipulating the class loader property so that it will download code from an external site. So you can prevent the attack by disallowing modifications of the class loader and by disallowing your application to download and run code from external sites.

Be explicit! Explicitly allow binding of certain properties. This prevents the exploit from working as there is no valid use case that requires access to the class property. Explicitly whitelisting properties also makes sure users cannot change the id of the object bound to a form or altering data that is managed internally like “date of creation” or “last modified by” properties.

To prevent code from external sites being downloaded and executed you can make sure your applications behaves well when run with a security manager. While this is a common concept used for client side code like applets it is far less common for server side applications. Tomcat usually works well with a security manager though it is not enabled by default. Making sure you appplications works with a security manager is also a variant of being explicit: You explicitly grant certain privileges to your code bases and disallow everything else that might be abused by attackers.

What can system administrators learn from CVE-2010-1622?

Your applications should run in a demilitarized zone where they are unable to access the internet or your intranet. If you really need access to external resources use a proxy server and white list the URLs your application needs to contact. Doing so prevents attackers from making your application download external code.

If your applications are built in a way that they work with a security manager use it! For Tomcat there is a short Howto available.

Spring Framework Security Vulnerability Part 1

Spring Source recently published CVE-2010-1622. The advisory describes a vulnerability that affects Spring Framework prior to 3.0.3 and allows attackers to execute arbitrary code.

What could SpringSource have done better?

When Spring Source announced the release of 3.0.3 they reported to have fixed “more than a hundred minor issues” — no indication of the security fix. This could be understandable as they have released the fix 2 days prior to publishing the advisory. I do not understand why they did not announce it later however. The advisory was published as silently as possible although the vulnerability is rated critical, can be exploited remotely and probably affects a large number of applications.
I would have preferred receiving the security advisory through the usual channels used for announcements in addition to the security team page.

Having a look at reveals another interesting fact. The CVE id was assigned on April, 29th. That is almost 2 months before the advisory was published. The bug was fixed on May, 27th.
Why does it take more than 4 weeks for a 3 line fix? Why does it take almost 3 additional weeks after the fix to announce the vulnerability?
I would have preferred a priority fix as soon as possible after discovery and a release following short time after that.

Finally SpringSource dicided not to provide a fixed release for dm Server, a product based on Spring Framework, which is also vulnerable. Users are advised to manually patch it instead. SpringSource also continues to provide the vulnerable dm Server 2.0.2 for download without any warning.
I would have preferred to receive a fixed release of dm Server instead of seeing SpringSource continue to ship products containing known security issues.

What can you learn from CVE-2010-1622?

I will follow up with the lessons learned for application developers and system administrators in the next days. Stay tuned.

There is also an interesting analysis of the issue at

SSO for RoundCube Webmail with Atlassian Crowd

Atlassian Crowd is a single sign-on and identity management tool by Atlassian that integrates well with their suite of software engineering and collaboration tools like JIRA, Confluence and Crucible. It offers a SOAP API that allows integration into arbitrary third-party systems. Integrating a webmail system with Crowd is quite easy. I’ve choosen RoundCube Webmail 0.2.2 as an example. RoundCube is based on PHP and has a nice and clean user interface and a well-written code base.

Step 1: Basic Integration

There is a PHP integration library that can be used as a starting point. It provides the methods for SSO but lacks the convenience of Crowd’s HttpAuthenticator. Implementing a simple PHP version of the HttpAuthenticator was the first step. My implementation uses APC to store the application token and validates every request with Crowd.

Step 2: Dovecot Masteruser

While the original version of RoundCube uses the user’s username and password to connect to the IMAP store that’s no longer possible with the crowdified version as it doesn’t have access to the user’s password. One solution is to use dovecot’s masteruser feature. With that configuration in place RoundCube can access the user’s mailbox by using its own password instead of the user’s password.

Step 3: Configuration

That’s it. Quite simple. If you like you can have a look at my patch. Check config/ and provide the username and password of your dovecot masteruser as well as the application name, credential and service URL for Crowd.

Security Issues Caused By External Hosting

Thomas has a nice example of how Deutsche Lufthansa has leaked personal data through an entertainment site operated by an external agency.

Most companies have strict rules for handling personal data and installed security policies for secure handling of sensitive information. Therefore enterprise data centers are usually quite secure. However the corporate processes that are required to keep the standards high are slow and expensive. This causes some companies to skip them in favor of faster and cheaper alternatives.

One solution is to accept hosting offers by the agencies that build the sites. The problem is that they are seldomly capable of providing a secure environment. It’s just not their business. The result is that sites with sensitive data are operated in shared hosting environments by unskilled persons out of control of corporate IT. It’s only a matter of time until security issues pop up and companies can be glad if they are informed before any data is stolen.

It just doesn’t make sense to harden the front door if you open up a few back doors at the same time. The best security policies are worthless if companies are willing to bypass them for faster and cheaper alternatives. Maybe Thomas’ story will help showing the value of corporate IT to those seeking alternatives without looking at the consequences.

Installing OpenVPN on OpenSolaris 2008.11

This is a short step-by-step howto that shows how I’ve installed OpenVPN on OpenSolaris 2008.11.

Step 1: Install GCC

# rolemod -K type=normal root
# pkg install SUNWgcc

Step 2: Install the TUN/TAP Driver

Grab the TUN/TAP driver for Solaris, unpack it in /usr/local/src and configure it:

# mkdir -p /usr/local/src
# cd /usr/local/src
# wget
# tar xvfz tuntap.tar.gz
# chown -R root:root tuntap
# cd tuntap
# ./configure

On 64bit you must modify the generated Makefile to call ld with the correct options. Add a LDFLAGS variable and replace $(LD) by $(LD) $(LDFLAGS):

LDFLAGS = -melf_x86_64
modules: tun.o tap.o
        $(LD) $(LDFLAGS) -r -o tun tun.o
        $(LD) $(LDFLAGS) -r -o tap tap.o

Run make and make install. The errors from /usr/sbin/rem_drv can be ignored as the module usually wasn’t installed before so it obviously can’t be removed.

Step 3: Install OpenVPN

Grab the latest RC of OpenVPN 2.1 (currently 2.1rc15) and unpack it in /usr/local/src:

# cd /usr/local/src
# wget
# tar xvfz openvpn-2.1_rc15.tar.gz
# chown -R root:root openvpn-2.1_rc15
# cd openvpn-2.1_rc15

You must replace tun.c from OpenVPN with the corresponding patched file:

# wget -O tun.c
# ./configure --disable-lzo
# make
# make install

If you do not disable LZO compression you must install the LZO library and headers before. We don’t use it so we don’t bother.

The OpenVPN binary is now available in /usr/local/sbin/openvpn.

Step 4: Configure OpenVPN

Configuration of OpenVPN is not different on Solaris than on any other supported platform. You can find the detailed documentation in the OpenVPN Howto.

If you get a Can't set PPA 1: File exists (errno=17) error and OpenVPN exits the tun interface may still be plumbed. Remove it with

# ifconfig tun0 unplumb

Openfire Server Multiple Vulnerabilities

Andreas Kurtz has published a security advisory regarding multiple critical security vulnerabilities in Openfire‘s admin console. There is also a posting to full-disclosure.
The issues allow a remote attacker to circumvent authentication and run arbitray code with the permissions of the user running Openfire. It affacts all versions up to and including 3.6.0a.

Andreas claims to have notified the vendor Jive Software six months ago. Up to now no security advisory has been issued by Jive and no patch has been published. I am really interested to hear Jive’s version of this story. If it is true that Jive was aware of the issues for so long and no action has been taken to inform the community or to fix the problem this will probably result in a loss of trust in Openfire’s development model.

For now the only solution is to limit access to the admin console by firewall rules. With regard to security issues in the admin console in the past this is recommended anyway. The XMPP interface is not accected by the vulnerabilities discovered by Andreas.

Update 2008-11-14

Openfire 3.6.1 has been released that fixes the security issues.


MobileKnox: Your Mobile Password Safe

Though there are some great ideas around to provide a global single sign-on infrastructure for web applications like OpenID today’s reality is different:

  • usually one account per web site – hopefully with different passwords
  • IMAP accounts for email
  • accounts for instant messaging networks (MSN, ICQ, Jabber)
  • accounts for your workstations at work, at home and for your notebook
  • PINs for your various credit and debit cards
  • account numbers and PINs for online and telephone banking
  • access codes for door locks and physical access control
  • and you probably can think of a lot more…

MobileKnox aims to make your life a bit easier by providing a secure store for your account data on your mobile phone.

If you are like me your mobile will always be with you. That means you will always have access to your credentials whether you are at work, at home or on the road.

MobileKnox runs on most Java-enabled mobiles and PDAs and is accompanied with a small desktop application that runs on all major platforms (Windows, Mac, Linux) to synchronize passwords with your device.