Source |
ProjectZero |
Identifiant |
8221924 |
Date de publication |
2022-11-04 07:39:42 (vue: 2022-11-25 18:05:33) |
Titre |
Gregor Samsa: Exploiting Java\'s XML Signature Verification |
Texte |
By Felix Wilhelm, Project ZeroEarlier this year, I discovered a surprising attack surface hidden deep inside Java's standard library: A custom JIT compiler processing untrusted XSLT programs, exposed to remote attackers during XML signature verification. This post discusses CVE-2022-34169, an integer truncation bug in this JIT compiler resulting in arbitrary code execution in many Java-based web applications and identity providers that support the SAML single-sign-on standard. OpenJDK fixed the discussed issue in July 2022. The Apache BCEL project used by Xalan-J, the origin of the vulnerable code, released a patch in September 2022. While the vulnerability discussed in this post has been patched , vendors and users should expect further vulnerabilities in SAML.From a security researcher's perspective, this vulnerability is an example of an integer truncation issue in a memory-safe language, with an exploit that feels very much like a memory corruption. While less common than the typical memory safety issues of C or C++ codebases, weird machines still exist in memory safe languages and will keep us busy even after we move into a bright memory safe future.Before diving into the vulnerability and its exploit, I'm going to give a quick overview of XML signatures and SAML. What makes XML signatures such an interesting target and why should we care about them?IntroductionXML Signatures are a typical example of a security protocol invented in the early 2000's. They suffer from high complexity, a large attack surface and a wealth of configurable features that can weaken or bre |
Envoyé |
Oui |
Condensat |
#signed &= instruction log reference return throw validationstatus // calcdigestvalue constantpoolgen data if listreference> throws validated validationstatus version= * */ protected method u1 u2 u4 xmlns= // 0x06 a add an at constant developers exploiting going in java keyinfo openjdk saml signaturevalue so the this validating while xslt xsltc /** * /> /> /> exposing /> 9bc34549d565d9505b287de0cd20ac77be1d3f2c />jeb />there />we />xsl:value /input 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008344026969402015 0x00 0x00000004data 0x00000005data 0x0001attribute 0x0001name 0x0003 attribute 0x00const 0x01 0x02 0x0200 0x03const 0x04 0x0400 0x05 0x06 0x0600length 0x0601 name 0x07 0x08 0x0807 0x10703 0x206 0x702 0x703 0x704 0x704:= 0xaa 0xaaconst 0xaafirst 0xcc 0xcccc 0xccdd 0xdd 0xdddd 0xxx 0xxxxxdesc 0xyy 0xyyyy attr 0xzz 0xzz06length 0xzzaccess 0xzzconst 0xzzzzzzzzdata 19991116 2**16 2000 2022 34169 65535 ; ; ; boolean ; validaterefs ; validationstatus ; boolean ; il ; instructionlist ; u2 ;turns > > > > > … &nb |
Tags |
Vulnerability
|
Stories |
|
Notes |
|
Move |
|