The security world held our collective breaths early this week for the big OpenSSL vulnerability announcement. Turns out it’s two separate issues, both related to punycode handling, and they’ve been downgraded to high severity instead of critical. Punycode, by the way, is the system for using non-ASCII Unicode characters in domain names. The first vulnerability, CVE-2022-3602, is a buffer overflow that writes four arbitrary bytes to the stack. Notably, the vulnerable code is only run after a certificate’s chain is verified. A malicious certificate would need to be either properly signed by a Certificate Authority, or manually trusted without a valid signature.
A couple sources have worked out the details of this vulnerability. It’s an off-by-one error in a loop, where the buffer length is checked earlier in the loop than the length variable is incremented. Because of the logic slip, the loop can potentially run one too many times. That loop processes the Unicode characters, encoded at the end of the punycode string, and injects them in the proper place, sliding the rest of the string over a byte in memory as a result. If the total output length is 513 characters, that’s a single character overflow. A Unicode character takes up four bytes, so there’s your four-byte overflow.
Now, how exploitable this overflow manages to be depends on what is in those four bytes. When Datadog researchers tested the vulnerability on Linux, they found that essentially every compiled binary had a 4-byte section of free memory here, that was initialized only after the overflow. In other words, on those binaries, this vulnerability is entirely benign. On Windows, that section of memory was handled differently by the compiler, due to different optimizations. Here, it contains a stack canary. That’s a special value that exists between the last buffer on the stack, and the pointer and return values. At the end of a function using a stack canary, the value is validated before returning to the parent function, and the processes crashes if it’s been tampered with. The idea is that a buffer overflow that overwrites the return address wouldn’t be able to predict the canary value, and canaries tend to intentionally include terminator bytes like 0x00 to make exploit even harder. Note that the Linux binaries also use stack canaries, which would prevent exploit, but because of the memory layout and limited overflow length, these aren’t ever modified.
The second issue fixed was CVE-2022-3786, and Checkpoint Security took a shot at explaining this one. In the case of Punycode followed by a dot, that dot is appended to the end of the output string, potentially past the end of the buffer. It’s the inverse of the previous vulnerability. Here the length of overflow is nearly arbitrary, but the value is locked to just the dot symbol. As a result, this one is strictly a Denial of Service problem.
Thankfully the sky isn’t falling with these vulnerabilities, but there could still be unanticipated cases where OpenSSL isn’t compiled with stack canaries, or the crash could be used as part of a more complicated exploit chain, so still be sure to grab the updated or backported patch if you’re running the vulnerable library, versions 3.0.0-3.0.6.
Security Researchers Turn to the Dark Side?
Betteridge’s law of headlines is certainly in play here. This story is just odd, as someone has launched a ransomware attack, that is also protestware, and also claims to be the work of some notable security researchers. So, is Bleeping Computer really behind this ransomware campaign that also protests the lack of support for Ukraine from the West? Oof, there’s a lot to unpack here.
First, it appears to not even be ransomware, as there’s no way to purchase a decryption key. So more properly it’s a wiper. The name used in the wiper note is “Azov”, a special forces regiment in Ukraine with an oddball neo-Nazi past, which happens to play into Russian rhetoric about their war there. Then the note claims to be from Hasherezade, and lists several security researcher Twitter handles. Then mentions Crimea and complains about not enough help for Ukraine. jThere’s a specific message for the people of the US, calling out president Biden, calling for revolution and then dropping the “Keep America Great” slogan. Then a message to Germany, helpfully run through Google Translate gives us: “You! A man from Germany, come on, come out!
But that’s a catastrophe that Biden has brought to them. How nice was it when Merkel was there?” And then even more bizarre, the note ends with the hashtag “#TaiwanIsChina”, which seems to be a slogan of the CCP sponsored rhetoric around Taiwan.
It’s hard to figure out exactly what is up with this campaign. It’s obviously not what it claims to be. A pro-Russia or anti-Russia hacker trying to gin up support? Something else entirely, using the geopolitics for cover? The infections all seem to be the result of SmokeLoader, one of the malware-as-a-service botnets. Pay some money, push your payload to machines on the botnet. Just a reminder, if you or someone you know does get hit by one of these campaigns, law enforcement offices do want to get record of it. In order to locate and prosecute the criminals behind these enterprises, they need some concrete cases to start with. And as much as it seems like ransomware criminals will never get caught, they do get identified and caught.
Project Zero Resists Calling it XML4Shell
[Felix Wilhelm] found a Java problem, and to our shared delight, he didn’t feel the need to contrive a “4shell” moniker for it. This story starts with SAML, Security Assertion Markup Language, the XML-based protocol that powers much of the web’s single-sign-on support. You want to visit website X, a Service Provider (SP) and use your account from website Y, your Identity Provider (IdP). The SP generates a SAML request, in the form of an XML document, and your browser send that document to the IdP. The IdP confirms that you do have an account there, and sends back an XML signature, via the browser. As it’s an obvious potential problem for the user’s browser to be the one handling the sign-on data, the data itself is verified as part of the signature. The whole process is complicated and one of the complexities is that a signature can include references to other signatures. Before the signature is fully verified, the signed XML document may need to go through several transformative steps, and eXtensible Stylesheet Language Transformations (XSLT) language is supported. Yeah, it’s a turing-complete language right in your SAML objects. And if the code doing the verification didn’t switch on secureValidation, the code gets compiled into Java code for the performance boost.
Part of this compilation process is converting values in the XSLT input to the Java constant pool. That pool has a limited size, and the compilation process doesn’t correctly do bounds checking. What happens when you write past the end of the pool? That data is understood as class fields — fields like method definitions. Do the work to make valid values for the three fields this overflow will clobber, and you have the ability to run arbitrary bytecode. This works for any Java application that handles XML signatures — in theory. The big caveat is that secureValidation disables all XSLT transformations, but that was only turned on by default in JDK 17.
urlscan.io Holds Secrets
The service provided by urlscan.io is actually pretty useful. Feed it a web link, and it will load it, preview the page for you, and spit out some statistics about it. Somebody send a weird link, and you don’t want to open it on your machine? Here’s your solution. The only thing to keep in mind is that unless you explicitly mark the scan as private, the link and results are publicly viewable. Github got bit by this last year, accidentally leaking private repository names to the service. This made [FABIAN BRÄUNLEIN] wonder, had other services made a similar mistake? Yes. There are links to private Google documents, API keys, Sharepoint and Zoom invites, and more. Apparently several automated security services push links to the service without any user interaction, and don’t use the API properly. Whoops.
0 Commentaires