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.

Java Applications on Privileged Ports

I am running most of my Java applications with Java Service Wrapper on Ubuntu. Most of these applications can run on unprivileged ports above 1024, e.g. Tomcats running behind an Apache http reverse proxy or the Openfire XMPP server that uses ports above 1024 by default. However there are exceptions like the LDAP server ApacheDS or Tomcats that do not require the features of httpd in front of them.

If you want to run Java applications on privileged ports below 1024 there are several options you can choose from:

To use authbind follow these steps:

Step 1: Install and configure authbind

Install authbind from the Ubuntu repository:

# aptitude install authbind

For each port your application should be able to bind to create a file in /etc/authbind/byport and make in executable by the user that runs your application. For ApacheDS I did the following:

# cd /etc/authbind/byport
# touch 389 636
# chown apacheds:apacheds 389 636
# chmod 700 389 636

This results in the following files:

# ls -l /etc/authbind/byport/
total 0
-rwx------ 1 apacheds apacheds 0 2010-05-04 21:24 389
-rwx------ 1 apacheds apacheds 0 2010-05-04 21:24 636

More information on access control is available in authbind (1).

Step 2: Update wrapper.conf

Authbind works by overloading the bind function in libc. This is done by setting the environment variable LD_PRELOAD. If you are using Java Service Wrapper the easiest way to do this is to add the following line to your wrapper.conf:

set.LD_PRELOAD=/usr/lib/authbind/libauthbind.so.1

As authbind only supports IPv4 you must prevent your application from binding to the IPv6 port as well. This can be achieved by setting the system property java.net.preferIPv4Stack in wrapper.conf:

wrapper.java.additional.1=-Djava.net.preferIPv4Stack=true

That’s it!

This approach works with any Java application and is not limited to ApacheDS. Have a look at A Better Tomcat for Ubuntu and Debian by MuleSource to see how they are using authbind without Java Service Wrapper to make Tomcat run on standard HTTP ports.

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.

JBoss Admin Console

JBoss AS 5.1.0-CR1 is out and finally includes a brand new admin console:

After installing JBoss AS 5.1.0 you can access it at http://localhost:8080/admin-console. Login with user “admin” and password “admin”.

The project behind the admin console is Embedded Jopr a web-based application for managing and monitoring an instance of JBoss AS. It is the little brother of Jopr. Jopr is a full-fledged systems management tool that helps managing and monitoring multiple instances of JBoss AS, Apache Webserver, Tomcat and more. The advantage of Embedded Jopr is that it is available out of the box and does not need any external resources like a database or separate agents. I am sure it makes operating JBoss AS a lot easier and more fun.

Give it a try and download the latest version.

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 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

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

Deleted a File by Accident?

You have deleted a file or directory and commited your change by accident? Subversion lets you undo your change quite easily.

Use svn merge -c -<revision> <URL> in your working directory. If you have local changes that you want to commit later do a fresh checkout of <URL> to a temporary directory and run svn merge there. After running svn merge you must commit your working directory for the undo to become effective.

As this completely reverses your change the same procedure can be used to recover a deleted directory or to undo other unwanted changes.

For more information see the undo section in Version Control with Subversion.

Using Kernel-based Virtualization

Recently I stumbled upon KVM (for Kernel-based Virtual Machine) which allows you to leverage the virtualization features built into modern processors.

This blog entry got me started. I am running Ubuntu Gutsy Gibbon 7.10 on an AMD Athlon(tm) 64 X2 Dual Core Processor so I installed qemu and kvm, loaded the kernel module and created a disk image for my virtual machine:

sudo apt-get install qemu kvm
sudo modprobe kvm-amd
qemu-img create node1.img -f qcow2 6G

Next I added myself to the kvm group to access /dev/kvm. As an alternative you can temporarily loosen the permissions (sudo chmod 666 /dev/kvm) but don’t forget to fix that later on.

I grabbed the iso image of the server edition of Ubuntu 7.10 and was ready to boot the vm and start the installation:

kvm -m 750 -cdrom ubuntu-7.10-server-amd64.iso -boot d -std-vga node1.img

Wow! That was easy:

I installed Ubuntu just like on every other computer. Once the installation was done the automatic reboot failed as expected and I closed the qemu window and started it again (this time with only 500MB of RAM which is still plenty):

kvm -no-acpi -m 500 node1.img

I booted a fully running Ubuntu system – even networking automagically worked.

This looks like a great alternative to the bloated VMware server especially as it is extremly easy to just copy or move the virtual machines if you want to play with clustering for example.

Read more here and here (yes, you can also run Windows this way). Cool stuff!

Book: Release It!


Michael T. Nygard’s book on releasing resilient enterprise software is a nice mixture of real world case studies and hands on tips for designing robust applications.

The book is organized in four parts:

  • Stability
  • Capacity
  • General Design Issues
  • Operations

Each part features case studies, patterns to apply and anti-patterns to avoid. For stability Michael advocates cynical software:

Cynical software expects bad things to happen and is never surprised when they do. Cynical software doesn’t even trust itself, so it puts up internal barriers to protect itself from failures. It refuses to get too intimate with other systems, because it could get hurt.

The patterns to achieve the decoupling include “Use Timeouts”, “Circut Breaker” and “Fail Fast” — things you’ve probably already applied from time to time, summarized and put into context.

Technology is centered around on what you find in today’s enterprises: Java EE app servers like Bea Weblogic, Oracle databases, Big IP F5 load balancers, Veritas Cluster Server, Sun boxes with Solaris from small V440s to the large E25K.

The book is focused on architecture and design so you will find only a few code snippets to illustrate concepts or specific flaws. It’s neither a cookbook for the developer nor an academic paper that sells a methodology. Instead it contains hands-on experience and provides a good overview of the areas to look for to avoid common pitfalls when designing resilient applications for today’s enterprise environments.

Available at Pragmatic Bookshelf.

Openfire 3.3.1 fixes critical Security Issue

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