Nvidia’s GeForce Experience (GFE) is the companion application for the Nvidia drivers, keeping said drivers up to date, as well as adding features around live streaming and media capture. The application runs as two parts, a GUI, and a system service, using an HTTP API to communicate. [David Yesland] from Rhino Security Labs decided to look into this API, searching for interesting, undocumented behavior, and shared the results on Sunday the 2nd.

The first interesting finding was that the service was written in Javascript and run using Node.js. Javascript is a scripting language, not a compiled language — the source code of the service was open for studying. This led to the revelation that API requests would be accepted from any origin, so long as the request included the proper security token. The application includes an update mechanism, which allows an authorized API call to execute an arbitrary system command. So long as the authentication token isn’t leaked to an attacker, this still isn’t a problem, right?

Modern browsers include a mechanism to fill the clipboard with arbitrary text. You’ve used this any time you “click here to copy to clipboard”. It’s also possible to launch a file upload dialog from javascript. The researcher’s suggested exploit is to trick the user into using the ctrl+v key combination, followed by the enter key. Perhaps a dialog asking someone to paste a reference number into a field, and pressing enter to continue. What would actually happen is that the page would detect the control keystroke, fill the clipboard with the location of the security token, and launch the file upload dialog. The user presses “v”, which pastes the contents of the clipboard into the dialog, and finally “Enter” starts the file upload. As soon as an attacker has the security token, an HTTP request can be made to the local API, launching an arbitrary command.

Nvidia was made aware of the potential issue, released a patch, and has published a security bulletin about it. [David] acknowledges the fix, but points out that the underlying issue, allowing API requests from any origin, still exists. He suggests that anyone not actively using GFE go ahead and uninstall it.

Ransomware As a Service Retires

GandCrab is a Ransomware-as-a-Service (RaaS?) offering that has been run like a business since early 2018. It has an online storefront where criminals can subscribe to the service and get custom built malware. The RaaS authors take a small cut of any ransom that is paid. Apparently that business has done very well for GandCrab, as they announced their retirement. They claim to have made over $150 million in the year and a half they have run this illicit service, and are now “…leaving for a well-deserved retirement. We have proved that by doing evil deeds, retribution does not come.”

While the chutzpah is admirable, the details are probably not entirely trustworthy. A declaration like that, especially after running a ransomware service, paints a rather large target over the heads of those responsible. Time will tell if the audacity is warranted.

TOCTOU and Docker

Docker was arguably the project that brought containerization back to its current popularity. More efficient than a full virtual machine while boasting nearly the same security advantages, Docker based solutions are particularly useful. A Time Of Check Time Of Use (TOCTOU) flaw has recently been found by [Aleksa Sarai]. In a Docker function, FollowSymlinkInScope, a maliciously crafted docker image could potentially read and write to any file on the host machine during a docker copy operation.

We’ve never talked about TOCTOU bugs on Hackaday, so a primer is in order. The standard pronunciation seems to be “TOCK too”, though spelling the acronym is also acceptable. FollowSymlinkInScope, for example, takes a given path and verifies that any symlinks point to locations inside the docker image, correcting any symlinks that would otherwise point to the host system. That is the “Check” in TOCTOU. The path is safely resolved, and eventually used to copy files to their correct locations, the “Use” element. The key here is the span of time between running the check, and making use of the path. An attacker can essentially race against that time span, making a change to the symlinks on the disk after the check has completed. The fundamental flaw of a TOCTOU is the assumption that once some element has been checked, it will remain in the same state until acted upon.

To understand why TOCTOU bugs are hard to fix, we have to consider how modern multitasking works, as well as atomic operations. In a single core processor, programs are constantly paused while other programs run. This idea goes all the way back to the first time-sharing systems of the 1970s. Modern multi-core processors exacerbate the potential for problem, as processes can run at the same time, all making changes to the same file system. An atomic operation is one that is completed all at once, without any other process able to observe or modify the process until it’s complete. Different operating systems and architectures provide different sets of atomic functions, making TOCTOU bugs very difficult to avoid. In the case of the Docker problem, [Aleksa] has suggested a new kernel function that allows resolving symlinks within a docker image automatically. In this case, the operation would become atomic by nature of the kernel performing the sanitization steps as part of accessing files.

Notepad and RDP

When a researcher discovers a vulnerability and writes a proof of concept, the payload launched is usually either calc.exe or notepad.exe. [Tavis Ormandy] turned this tradition on its head by discovering a vulnerability in notepad itself. In 90 days or once Microsoft fixes the issue, we’ll make sure to fill you in on the rest of the story.

The RDP vulnerability we covered a couple weeks ago, Bluekeep, is the story that keeps on giving. Two weeks after the patch was officially released, [Robert Graham] of masscan fame scanned the entire internet for vulnerable RDP services. He found at least 900,000 vulnerable machines. That’s nearly a million Windows machines that have RDP exposed to the internet that haven’t installed the security fix yet. This is why Microsoft considers Bluekeep such a huge problem.