Escalating Privileges In Ubuntu 20.04 From User Account

Ubuntu 20.04 is an incredibly popular operating system, perhaps the most popular among the Linux distributions due to its ease-of-use. In general, it’s a fairly trustworthy operating system too, especially since its source code is open. However, an update with the 20.04 revision has led to security researcher [Kevin Backhouse] finding a surprisingly easy way to escalate privileges on this OS, which we would like to note is not great.

The exploit involves two bugs, one in accountservice daemon which handles user accounts on the computer, and another in the GNOME Display Manager which handles the login screen. Ubuntu 20.04 added some code to the daemon which looks at a specific file on the computer, and with a simple symlink, it can be tricked into reading a different file which locks the process into an infinite loop. The daemon also drops its privileges at one point in this process, a normal security precaution, but this allows the user to crash the daemon.

The second bug for this exploit involves how the GNOME Display Manager (gdm3) handles privileges. Normally it would not have administrator privileges, but if the accountservice daemon isn’t running it escalates itself to administrator, where any changes made have administrator privileges. This provides an attacker with an opportunity to create a new user account with administrator privileges.

Of course, this being Ubuntu, we can assume that this vulnerability will be immediately patched. It’s also a good time to point out that the reason that open-source software is inherently more secure is that when anyone can see the source code, anyone can find and report issues like this which allow the software maintainer (or even the user themselves) to make effective changes more quickly.

This Week In Security: In The Wild, Through Your NAT, And Brave

Most of the stories from this week are vulnerabilities dropped before fixes are available, many of them actively being exploited. Strap yourselves in!

Windows Kernel Crypto

The first is CVE-2020-17087, an issue in the Windows Kernel Cryptography Driver. The vulnerable system calls are accessible from unprivileged user-space, and potentially even from inside sandboxed environments. The resulting buffer overflow can result in arbitrary code executing in the kernel context, meaning this is a quick jump to root-level control over a victim system.

What exactly is the code flaw here that’s being attacked? It’s in a bit of buffer allocation logic, inside a binary-to-hex conversion routine. The function accepts an unsigned short length argument. That value is used to calculate the output buffer size, by multiplying it by six, and using an unsigned short to hold that value. See the problem? A sufficiently large value will roll over, and the output buffer size will be too small. It’s a value overflow that leads to a buffer overflow.

Because the problem is being actively exploited, the report has been made public just seven days after discovery. The flaw is still unpatched in Windows 10, as of the time of writing. It also seems to be present as far back as Windows 7, which will likely not receive a fix, being out of support. [Editor’s snarky note: Thanks, closed-source software.] Continue reading “This Week In Security: In The Wild, Through Your NAT, And Brave”

This Week In Security: Discord, Chromium, And WordPress Forced Updates

[Masato Kinugawa] found a series of bugs that, when strung together, allowed remote code execution in the Discord desktop app. Discord’s desktop application is an Electron powered app, meaning it’s a web page rendered on a bundled light-weight browser. Building your desktop apps on JavaScript certainly makes life easier for developers, but it also means that you inherit all the problems from running a browser and JS. There’s a joke in there about finally achieving full-stack JavaScript.

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 contextIsolation options were set, and so both defaulted to false. What does this setting allow an attacker to do? Because the front-end and back-end JavaScript runs in the same context, it’s possible for an XSS attack to override JS functions. If those functions are then called by the back-end, they have full access to Node.js functions, including exec(), at which point the escape is complete.

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?

Enter bug #3. If the top page and the iframe are on different domains, the code preventing navigation never fires. In this case, JavaScript running in an iframe can redirect the top page to a malicious site, which can then override core JS functions, leading to a full escape to RCE.

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.

Continue reading “This Week In Security: Discord, Chromium, And WordPress Forced Updates”

This Week In Security: Too Little Too Late, And Other Stories

Microsoft has just announced a way to disable JScript in Internet Explorer. This would have been very useful a few years ago, to proactively prevent problems found in the now-ancient JScript engine, which ran their own slightly different version of standard JavaScript. Even though IE is no longer under active development, it still receives security updates. JScript, on the other hand, is basically done. If you’re one of the 1.06% that still use IE, then go flip the switch to protect yourself from additional JScript vulnerabilities.

Zerologon and Samba?

Samba is an open source re-implemenation of Microsoft’s SMB protocol. There’s a clever term that describes the reality of this situation: “Bug for bug compatibility”. Remember Zerologon, the flaw where a security token’s generation could be manipulated to vastly reduce the key space? Samba follows the specification, and therefore suffers from the same issue, though it seems to be unusual to actually run Samba in a vulnerable configuration.

Other implementations cannot say the same. QNAP in particular has been bitten by Zerologon when configured as a domain controller. What’s not clear is whether QNAP is running Samba on the NAS products, or if this is yet another vulnerable implementation. Either way, go update your devices. Continue reading “This Week In Security: Too Little Too Late, And Other Stories”

Do Your Part To Stop The Robot Uprising

One of the pleasures of consuming old science fiction movies and novels is that they capture the mood of the time in which they are written. Captain Kirk was a 1960s guy and Picard was a 1990s guy, after all. Cold war science fiction often dealt with invasion. In the 1960s and 70s, you were afraid of losing your job to a computer, so science fiction often had morality tales of robots running amok, reminding us what a bad idea it was to give robots too much power. As it turns out, robots might be dangerous, but not for the reasons we thought. The robots won’t turn on us by themselves. But they could be hacked. To that end, there’s a growing interest in robot cybersecurity and Alias Robotics is releasing Alurity, a toolbox for robot cybersecurity.

Currently, the toolbox is available for Linux and MacOS with some support for Windows. It targets 25 base robots including the usual suspects. There’s a white paper from when the product entered testing available if you want more technical details.

Continue reading “Do Your Part To Stop The Robot Uprising”

Google Meddling With URLs In Emails, Causing Security Concerns

Despite the popularity of social media, for communication that actually matters, e-mail reigns supreme. Crucial to the smooth operation of businesses worldwide, it’s prized for its reliability. Google is one of the world’s largest e-mail providers, both with its consumer-targeted Gmail product as well as G Suite for business customers [Jeffrey Paul] is a user of the latter, and was surprised to find that URLs in incoming emails were being modified by the service when fetched via the Internet Message Access Protocol (IMAP) used by external email readers.

This change appears to make it impossible for IMAP users to see the original email without logging into the web interface, it breaks verification of the cryptographic signatures, and it came as a surprise.

Security Matters

A test email sent to verify the edits made by Google’s servers. Top, the original email, bottom, what was received.

For a subset of users, it appears Google is modifying URLs in the body of emails to instead go through their own link-checking and redirect service. This involves actually editing the body of the email before it reaches the user. This means that even those using external clients to fetch email over IMAP are affected, with no way to access the original raw email they were sent.

The security implications are serious enough that many doubted the initial story, suspecting that the editing was only happening within the Gmail app or through the web client. However, a source claiming to work for Google confirmed that the new feature is being rolled out to G Suite customers, and can be switched off if so desired. Reaching out to Google for comment, we were directed to their help page on the topic.

The stated aim is to prevent phishing, with Google’s redirect service including a link checker to warn users who are traveling to potentially dangerous sites. For many though, this explanation doesn’t pass muster. Forcing users to head to a Google server to view the original URL they were sent is to many an egregious breach of privacy, and a security concern to boot. It allows the search giant to further extend its tendrils of click tracking into even private email conversations. For some, the implications are worse. Cryptographically signed messages, such as those using PGP or GPG, are broken by the tool; as the content of the email body is modified in the process, the message no longer checks out with respect to the original signature. Of course, this is the value of signing your messages — it becomes much easier to detect such alterations between what was sent and what was received.

Inadequate Disclosure

Understandably, many were up in arms that the company would implement such a measure with no consultation or warning ahead of time. The content of an email is sacrosanct, in many respects, and tampering with it in any form will always be condemned by the security conscious. If the feature is a choice for the user, and can be turned off at will, then it’s a useful tool for those that want it. But this discovery was a surprise to many, making it hard to believe it was adequately disclosed before roll-out. The question unfolded in the FAQ screenshot above hints at this being part of Google’s A/B test and not applied to all accounts. Features being tested on your email account should be disclosed yet they are not.

Protecting innocent users against phishing attacks is a laudable aim,  and we can imagine many business owners enabling such a feature to avoid phishing attacks. It’s another case where privacy is willingly traded for the idea of security. While the uproar is limited due to the specific nature of the implementation thus far, we would expect further desertion of Google’s email services by the tech savvy if such practices were to spread to the mainstream Gmail product. Regardless of what happens next, it’s important to remember that the email you read may not be the one you were sent, and act accordingly.

Update 30/10/2020: It has since come to light that for G Suite users with Advanced Protection enabled, it may not be possible to disable this feature at all. 

This Week In Security: BleedingTooth, Bad Neighbors, And Unpickable Locks

This week, the first details of BleedingTooth leaked onto Twitter, setting off a bit of a frenzy. The full details have yet to be released, but what we know is concerning enough. First off, BleedingTooth isn’t a single vulnerability, but is a set of at least 3 different CVEs (Shouldn’t that make it BleedingTeeth?). The worst vulnerability so far is CVE-2020-12351, which appears to be shown off in the video embedded after the break.

Continue reading “This Week In Security: BleedingTooth, Bad Neighbors, And Unpickable Locks”