Java RMI uses the default Java deserialization mechanism for passing parameters during remote method invocations. In other words, RMI uses ObjectInputStream that is a well-known unsafe deserialization mechanism. If an attacker can find and send a deserialization gadget to a vulnerable remote method, in the worst case it can result in arbitrary code execution.
I recently wrote a CodeQL query that looks for dangerous remote objects registered in an RMI registry. This post describes the vulnerability and how the query works.
Recently I wrote a post about detecting JEXL injections with CodeQL. JEXL is a library that provides an interpreter for a simple expression language (EL). This time, I’ll talk about injections with Jakarta Expression Language, and how they can be found with CodeQL.
Recently WhiteSource security scanner started reporting WS-2016-7107 against Spring-based applications. This is an old issue in Spring Security that was reported in 2016. Unfortunately, at the moment of writing it, the issue has not been fixed yet. But there is a pull request that should address it. The problem is that CSRF tokens generated by Spring Security are vulnerable to the BREACH attack. The attack is even older — it was published in 2013. The BREACH attack is similar to the CRIME attack but BREACH doesn’t need TLS compression.
In this blog post, I’ll talk about detecting unsafe Spring Exporters with a CodeQL query. First, I’ll describe the issue that received CVE-2016-1000027. Next, I’ll show what a vulnerable code looks like and how the issue can be mitigated in an application. Then, I’ll describe how the CodeQL query works. In addition, I’ll show a couple of vulnerabilities that have been found by the query.
In this post, I’ll talk about a CodeQL query for detecting JEXL Expression Language injection vulnerabilities. First, I’ll give a brief overview of expression languages in general and JEXL in particular. Next, I’ll explain what Expression Language injection is and how to prevent it. Then, I’ll describe how the CodeQL query works. In addition, I’ll show a couple of vulnerabilities that have been found by the query.
Some time ago I wrote about unsafe deserialization and DoS vulnerabilities I’ve discovered in Apache Olingo. This post describes one more issue in the library. This time, it’s a little flaw in the Olingo client which may allow sending some HTTP requests to arbitrary URLs. The issue has been fixed in the 4.7.1 release.
In case you don’t know, Apache Olingo is a Java library that implements the Open Data Protocol (OData). This protocol allows the creation and consumption of queryable and interoperable RESTful APIs in a simple way.
Some time ago I wrote about one security issue which I found in the library. This post describes another little vulnerability in Apache Olingo. The issue has been fixed in the 4.7.0 release as well.
By the way, Apache Olingo is a Java library that implements the Open Data Protocol (OData). This protocol allows the creation and consumption of queryable and interoperable RESTful APIs in a simple way.
The Java standard library provides the ObjectInputStream class which offers a convenient way for deserializing Java objects. Unfortunately, this way is not safe by default. Using this class may open the doors for Java deserialization attacks which in the worse case may result in arbitrary code execution.
I recently discovered that Spring Security OAuth2 library may be vulnerable to such an attack. Fortunately, there is one strong pre-requisite for a successful attack which may be difficult to meet for an adversary. Nevertheless, I thought it might be better to make the library a bit safer, and the project maintainers kindly accepted the contribution. Here are the details.
Apache POI is a popular Java library for working with Microsoft documents. For example, it allows you reading and writing Microsoft Excel files using Java. When I was recently looking into the library, I noticed a little vulnerability which then became CVE-2019-12415. The issue has been fixed in POI 4.1.1. Below are the details.