Weakness in Java TLS Host Verification

Unicode-related vulnerabilities have seen an increase in momentum in the past year. Last year, a Black Hat presentation by Jonathan Birch detailed how character normalization NFC/NFKC can lead to glitches in URL and host manipulation. Recently, two vulnerabilities were found in password reset functionality. The two affected applications were Django and Github. In the previous blog post, we have presented API transforming code points with potential side effects. In this post, we present one of our findings: a vulnerability affecting Oracle JDK and Open JDK host verification in the TLS communication. We are also including details from a similar weakness in Apache HTTP client.

Unicode for Security Professionals

Unicode is the de-facto standard for multilingual character encoding. UTF-8 is the most popular encoding used that supports its hundreds of thousands of characters. Aside from the encoding (byte representation of characters), Unicode defines multiple transformations that can be applied to characters. For instance, it describes the behavior of transformations such as Uppercase.

The character known as Long S “ſ” (U+017F) will become a regular uppercase S “S” (U+0053). Unexpected behavior for developers can often lead to security issues. Today, we will dive into the case mapping and normalization transformations. You will see how they can contribute to logic flaws in code.

Along with this article, we are sharing a list of API to look for in source code audit. We are also publishing an interactive cheat sheet for character testing.