Sticking with Head with OpenShift Image Streams – Red Hat Security Blog

Sticking with Head with OpenShift Image Streams


Using Openshift Container Platform ‘s2i’ with a TCP Docker daemon

I am using a Docker TCP socket to connect to a remote docker daemon. I run Docker on a remote host so that I can access my containers from both of my development machines. Of course the Docker TCP socket should be secured with TLS authentication in order to protect it from malicious use. You can read how to do that here.
Sometimes I want to make use of Docker images which we ship in the Red Hat Docker registry, but they are designed to be used in Openshift. They are not designed to be used ‘standalone’, but to be used with the ‘s2i’ tool, which is part of the Openshift Container Platform.
If you’ve tried to use ‘s2i’ with a Docker TCP socket, you might have found that you get this error message, “Unable to connect to Docker daemon. Please set the DOCKER_HOST or make sure the Docker socket “tcp://” exists“, and the ‘s2i’ manual pages hard to decipher. I had to dig into the source code to figure out the correct configuration to use. You need to set the following Environment variables:
export DOCKER_HOST=tcp://
export DOCKER_CERT_PATH=~/.docker/

Once you set those, you should be able to use ‘s2i’ to develop containerized apps locally using images from the Red Hat Docker Registry.

Deserialization in Java, collection of thoughts

Other languages have considered deserializing data a security issue, especially when done across a trust boundary, such as across a network. However Java has a long history of deserializing data sent from across the network, which started with the predecessor to EJB, CORBA.

Unfortunately lots of deserialization of untrusted data still goes on in modern Java applications. The reason its topical now, is that recent gadget chains tools created by Chris Frohoff and Gabriel Lawrence have made exploiting this type of weakness accessible by your average script kiddie.

Luckily JBoss, took steps years ago to reduce their exposure to deserialization by switching from a JMX MBean managment and configuration model, to a more secure management interface in JBoss AS 7. The new management interfaces only bind on the loopback network interface by default, and are secured with authentication out of the box.

That’s not to say that deserialization does not occur at all, and their taking steps to reduce their exposure further. Some of the tools you can use to find, and plug holes in Java applications include network packet sniffing with MITMProxy, and I plan to experiment with Direct Defence’s SuperSerial extender for Burp suite.

With the advent JDK9 the Java community is hoping to see some performance improvements in the Java Security Manager, such as JEP 232, as well as the introduction of ValueTypes. I also really like notsoserial put together by Kantega to blacklist risky classes from deserialization with byte code instrumentation, as a direct response to these kind of vulnerablities. Although I’d still consider it a band-aid approach.

The Java community have to be aware that the recently discovery of gadget chains utilizing the Apache commons-collections weakness are just the tip of the iceberg. The real solution is avoiding Java deserializaiton altogether. That means avoiding JMX Management over RMI, JMS ObjectMessage and others. Where we can’t avoid it, at least making sure those endpoints are protected by authentication. Thanks to Will Sargent, of Terse Systems for this inspiring blog post on the same topic.