We’ve looked at many vulnerabilities over the years here on Hackaday, but it’s rather rare for a CVE to score a perfect 10 severity. This is reserved for the most severe and exploitable of problems. Palo Alto announced such a vulnerability, CVE-2020-2021, on the 29th. This vulnerability affects Palo Alto devices running PAN-OS that have SAML authentication enabled and a certain validation option disabled. The vulnerability is pre-authentication, but does require access to a service protected by SAML authentication. For example, a Palo Alto device providing a web-based VPN could be vulnerable. The good news is that the vulnerable settings aren’t default, but the bad news is that the official configuration guide recommends the vulnerable settings for certain scenarios, like using a third party authentication service.
The issue is in the Security Assertion Markup Language (SAML) implementation, which is an XML based open standard for authentication. One of the primary use cases for SAML is to provide a Single Sign On (SSO) scheme. The normal deployment of SAML SSO is that a central provider handles the authentication of users, and then asserts to individual services that the connecting user is actually who they claim to be.
The setting needed for this vulnerability to be exploitable is ‘Validate Identity Provider Certificate’ to be disabled. If this option is enabled, the SSO provider must use a CA signed SAML certificates. This doesn’t appear to mean that unsigned SSL certificates would be accepted, and only applies to certificates inside the SAML messages. It seems to be widely accepted that these certificates don’t need to be CA signed. In the official announcement, the vulnerability type is said to be “CWE-347 Improper Verification of Cryptographic Signature”.
There isn’t much additional detail given about the vulnerability, except that it is considered very exploitable, and gives Admin level access to the attacker. The US Cyber Command went so far as to announce that we should expect foreign actors to begin using this vulnerability right away. We can take an educated guess as to what’s going on here. Because it’s classified as an improper verification attack, we can assume that information that is intended to be provided by the SSO provider can instead be provided by the attacker. The attack is likely a variation on this: An attacker makes a request for verification, but within the request, also includes a mostly valid spoofed response from the SSO provider, claiming that the request is valid. The victim device doesn’t properly handle the unexpected extra entries, and accepts the message.
It’s likely that a proof of concept will eventually be released, so hopefully we can come back to this vulnerability and see how accurate our guesses are.
Emergency Windows Patches for Cursed Images
A pair of Windows bugs have been patched outside the normal Patch Tuesday cycle. CVE-2020-1425 & CVE-2020-1457 are flaws in the Windows Codec Library, specifically in the handling of image codecs. An application that uses this library only needs to parse a malicious image in order to trigger code execution. Notable about these flaws and fixes is that they are not being patched through Windows Update, but through the Microsoft store.
VMware Escape Vulnerabilities
A pair of vulnerabilities in the VMware virtualization platform were recently disclosed. CVE-2020-3962 and CVE-2020-3969 both target the virtual SVGA device that provides graphical output for VMs. Both exploits require graphical acceleration to be enabled, which is the default state on some VMware products.
Not much information is given, beside the fact that one is a use-after-free problem, while the other is an off-by-one heap-overflow. What’s interesting is that both flaws allow escaping the virtualized environment and running code on the hypervisor. Many of us have a VM floating around for opening suspicious files, visiting known malicious links, and other assorted security research. The assumption there is that it’s almost impossible for malware to jump the gap back to the host machine. Vulnerabilities like this are a good reminder that this assumption doesn’t always hold up.
Malicious Music
My interest was piqued by the story of a minor vulnerability in TuxGuitar, a program for editing and viewing guitar scores. Guitar music is often written out in a unique format, tablature, often just called “tab” for short. This form of music is niche enough that several dedicated file formats and editors are dedicated to it. [Michael Dardas] was intrigued enough to take a look at the source code, and discovered some problems.
XML is a complicated beast with its own security problems. One of those potential problems is the XML External Entity (XXE) attack. Put simply, XXE is referencing some external service or document as part of an XML file. The TuxGuitar program doesn’t have sufficient checks for XXE in the XML-based tab files it loads. This means that a malicious tab file could reveal an IP address, exfiltrate a local file, or perform other limited unwanted actions.
Now, TuxGuitar isn’t a security focused application, and it’s likely that the authors didn’t think much about possible security flaws. This is an easy trap to fall into. However, even though there isn’t an immediately apparent attack vector, there is often still a way that vulnerabilities could be leveraged. I can imagine a targeted attack where a tab file is used to unmask a Tor user.
As far as I can tell, this issue isn’t being addressed in the upstream project, so if you do happen to use TuxGuitar, be wary of untrusted tab files.
Odds and Ends
If you haven’t checked it out yet, go look at the new Hackaday U series on reverse engineering with Ghidra! It’s a beginners guide to using the tool, and reverse engineering in general, presented by [wrongbaud].
All three major browsers have officially jumped onboard the one year SSL validity train. There’s been a bit of drama between browser vendors (Google and Apple) and the CA providers regarding this new policy. Not everyone seems happy about the change, but Firefox, Chrome, and Safari now refuse to honor SSL certs older than a year.
Last week we talked about Ripple20, a set of security problems present in a widely used TCP/IP stack. While the research itself was top notch, I took umbrage at a couple of details concerning their disclosure process. JSOF, the company behind the research, responded to my annoyances. Go check it out, particularly if you read it before their response was added.
I still don’t like giving up my email address to get access to the actual vulnerability paper, but I’ve seen several more reports of devices containing these vulnerabilities without having patches ready to fix those problems. In at least some cases, the vulnerabilities in question are indeed 0-day problems. Also, for what it’s worth, two of the nineteen issues also managed CVE scores of 10.