A critical security bug was fixed in Chrome recently, CVE-2020-6378. The CVE report is still marked private, as well as the bug report. All we have is “Use-after-free in speech recognizer”. Are we out of luck, trying to learn more about this vulnerability? If you look closely at the private bug report, you’ll notice it’s in the Chromium bug tracker. Chrome is based primarily on the Chromium project, with a few proprietary features added. Since Chromium is open source, we can go find the code change that fixed this bug, and possibly learn more about it.

Off to the Chromium source, mirrored on Github. We could look at every commit, and eventually find the one we’re looking for, but Chromium commit messages usually include a reference to the bug that is fixed by that commit. So, we can use Github’s search function to find a commit that mentions 1018677. Just like that, we’ve found a single commit and more information.

The shutdown mentioned in the commit message is possibly referring to the browser being closed, but could also refer to the tab doing the speech recognizing, or even the speech system itself. Because multiple parts are being unloaded in parallel, there is a race condition between calling the abort object, and that object being unloaded from memory. This race can result in a classic use-after-free, jumping code execution to a memory location that’s already been freed.

All interesting, but how does this warrant a Critical rating? Enter the Web Speech API. I’m speculating just a bit, but it’s likely that this API uses the speech recognizer code in question. It may even be interacting with the security prompt that triggers the crash. Imagine that an attacking page attempts to use the speech API, and then releases the API object before the user can respond to the prompt. That *might* be the scenario that was discovered, though we’re deep into speculation, now.

Remote Desktop Gateway

A pair of pre-authentication vulnerabilities were recently fixed in Microsoft’s Remote Desktop Gateway product. These vulnerabilities both revolve around UDP support, fragmentation, and what elements of an incoming packet can be trusted.

The first vulnerability is the most serious: The UDP fragment re-assembly code partially trusts the number of fragments claimed in the packet. A buffer is allocated based on that number. The code that copies incoming packets into the buffer first checks that the number of bytes copied won’t exceed the number of bytes allocated. It seems like this should be a sufficient check, but this ignores the offset to which the packet is written. A single packet can claim that there is only two packets, but set its own fragmentation number to an arbitrary value. The write offset is based off this value, and because the total number of written bytes don’t exceed the buffer length, the code happily writes the incoming data to an arbitrary location.

Robert Graham made the interesting point on twitter that this vulnerability exists even though the code here uses one of the supposedly safe memory copy routines, memcpy_s. This safe routine does prevent code from writing past the end of a buffer, but in this case, the entirety of the operation is outside the array, which is officially undefined behavior. Any time you see “undefined behavior”, just mentally replace it with “Really dangerous, destined to burn you in the future”.

The second vuln assumes that number of fragments will never be over 64. An array of 64 integers is allocated, to track which fragments have been received. When in incoming fragment is processed, so long as the fragment number is less than the indicated number of fragments, a 1 is written to the corresponding location in that array, even if it is past the end of the allocated memory.

Internet Explorer 0-day

The legacy jscript.dll scripting engine in IE 9, 10, and 11 has a vulnerability that is being exploited in the wild, related to the handling of objects in memory. Jscript is Microsoft’s re-implementation of Javascript, and pages can request their code run in the old engine, for compatibility.

Microsoft is waiting for the next patch Tuesday to push a fix, but has suggested a workaround. Set the jscript.dll file permissions to make it unreadable. There are a few downsides, like breaking MP4 playback in Windows Media Player, preventing the SFC scan from completing, and a few others.

We’re all waiting to see if Microsoft will opt to push the fix to Windows 7 next month. If not, mark this down as the first glaring problem with still running Windows 7 machines.

Citrix and Path Transversal

First off, several Citrix products contain CVE-2019-19781, a path transversal flaw. This style of flaw usually involves an attacker requesting a path that includes “..” to bypass security controls. In this case, an attacker can abuse the flaw prior to authentication, to download credentials or even get a remote shell.

It’s being actively exploited, so Citrix has moved their patch release date up to today (Friday, January 24). So far it’s unclear how many devices have been compromised, but this vulnerability is just about as serious as they come.

Connectwise and Ransomware

Connectwise is a remote desktop and management solution. It was apparently the attack vector used in the Texas ransomware attack last year that hit 22 separate municipalities. The vulnerabilities are simple, like cross site request forgeries, cross site scripting, and the like.

The most interesting part of this story might be Connectwise’s response. During a meeting, one of their executives threatened a defamation lawsuit. The vulnerabilities have been validated by a third party, so it’s likely the researchers are correct, and it’s likely this was the cause of the ransomware attack.

Google Groups hacking — GGvulnz

This last story blurs the line between a vulnerability and simple social engineering. [Milan Magyar] noticed that many companies use Google Groups, but don’t set the permissions properly. Simply exposing internal discussions can be problematic in and of itself, but there is something clever than can be done here. You see, many Google Groups use a dedicated email address that uses the companies domain name. That isn’t usually considered a problem, but what could an attack do with an email address on a company’s domain?

Some services, like Slack, can be configured to automatically approve new accounts, so long as they come from a company email address. The thought is that this generally limits access to employees. What if there was a way to trivially access a company email address?

Yep, that’s the attack. Set up a slack account, using mailinglist@companyname.com as the registration email. Then, go grab the confirmation link off the Google Group page, and enjoy your official Slack account.

The response [Milan] has gotten from Google, Slack, etc. is that while it’s a very clever attack, it’s not exactly a vulnerability in their system, it’s a misconfiguration by the customer. In some ways, this sort of problem is the most interesting to me. Nothing is technically broken, but the overlap of these policies leads to a very clever attack.

If you’re aware of something clever, interesting, or otherwise security newsworthy, be sure to let us know, and we’ll cover it next week!