Tag Archives: security

Spring Framework Security Vulnerability Part 2

Posted on by

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

Posted on by


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 cve.mitre.org 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 blog.o0o.nu.

SSO for RoundCube Webmail with Atlassian Crowd

Posted on by

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/main.inc.php 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

Posted on by

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

Posted on by

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 http://www.whiteboard.ne.jp/~admin2/tuntap/source/tuntap/tuntap.tar.gz
# 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 http://www.openvpn.net/release/openvpn-2.1_rc15.tar.gz
# 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 http://www.whiteboard.ne.jp/~admin2/tuntap/source/openvpn/2.1/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

Posted on by

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.

References

MobileKnox: Your Mobile Password Safe

Posted on by


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.

References

Openfire 3.3.1 fixes critical Security Issue

Posted on by

Ignite Realtime has released Openfire 3.3.1 which fixes a critical security issue in all versions prior to 3.3.1. I had reported the issue last week, so thanks to the Openfire guys for the quick fix.

The security issue allows malicious people to remotely upload code to Openfire via the built-in admin console. The code is executed with the permissions of the user running Openfire. It is highly recommended that users upgrade their server instances to fix this security issue.

As a workaround access to the admin console port (9090 by default) can be limited via firewall rules.

The full changelog is available here.

Update June 27, 2007:

Now over a month later that users had enough time to upgrade I can release a few more details about the issue:

Basically the problem was a missing filter mapping in web.xml which caused the beans used to install plugins which are exposed through DWR to be available without authentication.

Openfire Plugin Management

So you could easily open http://somehost:9090/dwr/test/downloader and upload a malicious plugin that would run with the privileges of Openfire and with full access to the Openfire database.

References: Secunia Advisory: SA25427, CVE-2007-2975,
JM-1049