The big security problem with Electron is that a simple Cross Site Scripting (XSS) bug is suddenly running in the context of the desktop, instead of the browser. Yes, there is a sandboxing option, but that has to be manually enabled.
And that brings us to the first bug. Neither the
sandbox nor the
Now that we know how to escape Electron’s web browser, what can we use for an XSS attack? The answer is automatic iframe embeds. For an example, just take a look at the exploit demo below. On the back-end, all I have to do is paste in the YouTube link, and the WordPress editor does its magic, automatically embedding the video in an iframe. Discord does the same thing for a handful of different services, one being Sketchfab.
This brings us to vulnerability #2. Sketchfab embeds have an XSS vulnerability. A specially crafted sketchfab file can run some JS whenever a user interacts with the embedded player, which can be shoehorned into discord. We’re almost there, but there is still a problem remaining. This code is running in the context of an iframe, not the primary thread, so we still can’t override functions for a full escape. To actually get a full RCE, we need to trigger a navigation to a malicious URL in the primary pageview, and not just the iframe. There’s already code to prevent an iframe from redirecting the top page, so this RCE is a bust, right?
It’s a very clever chaining of vulnerabilities, from the Discord app, to an XSS in Sketchfab, to a bug within Electron itself. While this particular example required interacting with the embedded iframe, it’s quite possible that another vulnerable service has an XSS bug that doesn’t require interaction. In any case, if you use Discord on the desktop, make sure the app is up to date. And then, enjoy the demo of the attack, embedded below.
Chromium Freetype Overflow
Chromium 86 has a fix for a particularly nasty bug. Tracked as CVE-2020-15999, this is a bug in how FreeType fonts are rendered. Now that Microsoft has switched to Edgium (Chromium powered Edge), we get two-for-one deals on Chromium vulnerabilities. This bug is interesting because it’s reportedly being actively exploited already. Google has marked the bug public, so we can take a closer look at exactly what happened.
The problem is in the FreeType library, regarding how fonts are handled when they contain embedded PNGs. To put it simply, the PNG width and height are stored in the font as 32-bit values, but those values are truncated to 16-bit before the buffer is allocated. After this, the PNG is copied to the buffer, but using the non-truncated values. A check is then performed to make sure the copy didn’t overflow, but unhelpfully, this was checked *after* the copy had taken place. The bug includes a test case, so feel free to go check your devices using that code. It’s not clear how long this bug has existed, but it’s possible it also affects Android’s System WebView, which is much slower to update.
Step-by-step of Chrome Exploit
The FBI, along with CISA and HHS, has issued a warning (PDF) about an ongoing redoubling of ransomware attacks against US hospitals and other healthcare providers. This attack is using the
Trickbot malware and the
Ryuk ransomware. They also note the use of DNS tunneling for data exfiltration, and specifically mention Point of Sale systems as a target.
The mitigation steps are particularly interesting in trying to read between the lines here. Before we look too deeply, I have to call out an outdated piece of advice: “Regularly change passwords”. This has been the bane of many users and administrators, and leads to weaker security, not stronger. With that out of the way, let’s look at the other recommendations.
A few recommendations are boiler-plate, like two-factor authentication, install security updates, have backups, etc. I was surprised to see the recommendation to allow local administration, in order to get things working again. What might be the most interesting is the recommendation to take a hard look at any RDP services that are running. Does this mean that some healthcare PoS system is running an out-of-date Windows, with a vulnerable RDP service open to the network by default, and it’s suddenly being targeted? Maybe. I’ve learned not to put too much stock in these advisories, unless actual details are given, and this particular example is quite light on details.
Loginizer’s SQL Injection
The popular Loginizer WordPress plugin is intended to protect your site’s login page from attack. It can add two-factor authentication, CAPTCHAs for repeated login attempts, and even detect brute-force attempts and blacklist the offending IP. That last one is where the problem lies. Incoming login attempts are logged to a SQL database, and that logging wasn’t properly sanitized, nor were prepared statements used. Because of this, the login page was subject to a very simple SQL injection attack. The Lesson? Sanitize your inputs, and use prepared statements! The latest update fixes this, as well as a separate but similar security issue.
What makes this bug novel is that WordPress found it a big enough problem to break the glass and push the big red button labeled “Force Update”. I didn’t know the folks at WordPress had a button that did that, but for particularly bad bugs like this one, it’s a useful capability. A few users complained that this update was installed even though they had auto-updates disabled. It’s a fine line to walk here, but it seems like WordPress should make it clear in the settings that this feature exists, and include a way to opt-out of forced updates like this one.