Git’s Large File System is a reasonable solution to a bit of a niche problem. How do you handle large binary files that need to go into a git repository? It might be pictures or video that is part of a project’s documentation, or even a demonstration dataset. Git-lfs’s solution is to replace the binary files with a text-based pointer to where the real file is hosted. That’s not important to understanding this vulnerability, though. The problem is that git-lfs will call the main git binary as part of its operation, and when it does so, the full path is not used. On a Unix system, that’s not a problem. The $PATH variable is used to determine where to look for binaries. When git is run, /usr/bin/git is automagically run. On a Windows system, however, executing a binary name without a path will first look in the current directory, and if a matching executable file is not found, only then will the standard locations be checked.

You may already see the problem. If a repository contains a git.exe, git.bat, or another git.* file that Windows thinks is executable, git-lfs will execute that file instead of the intended git binary. This means simply checking out a malicious repository gets you immediate code execution. A standard install of git for Windows, prior to 2.29.2.2, contains the vulnerable plugin by default, so go check that you’re updated!

Then remember that there’s one more wrinkle to this vulnerability. How closely do you check the contents of a git download before you run the next git command? Even with a patched git-lfs version, if you clone a malicious repository, then run any other git command, you still run the local git.* file. The real solution is pushing the local directory higher up the path chain.

Intel’s PLATYPUS

Intel has a new, interesting vulnerability fix in their processors, PLATYPUS. A series of OS updates, firmware releases, and even microcode patches have been released to deal with this new issue. We can take a look at the whitepaper (PDF) and decide, just how serious of an issue is PLATYPUS?

The mechanism at the center of PLATYPUS is Intel’s RAPL, the Running Average Power Limit interface. Put simply, it’s a real-time power meter for Intel CPUs. In the Linux kernel, that interface was exposed to unpriviledged users. Now what could an unpriviledged user do with such a power meter?

Apparently one of the demonstration attacks was able to map out the randomized Linux kernel address space, in about 20 seconds. From a privileged (root level) attack position, the secrets in Intel’s SGX Enclave can be discovered. How? It’s essentially the same problem as TEMPEST from the WWII era. Anything that leaks information about the internal state of a cryptography device can be used to attack the cryptography. In this case, it’s not radio emissions, but information emission in the form of power usage. There are some other clever elements to this story, like abusing a seperate bug to single-step processor functions, giving an attacker much finer resolution in their data gathering. It’s likely that in the next few months, we’ll see news about the PLATYPUS attack being used again AMD chips, and possibly even ARM processors.

TCL TVs

There’s an old adage, to never attribute to malice what can be explained by simple negligence. It’s unclear whether the problems that [sick codes] and [John Jackson] in certain TCL TVs can be fully explained by negligence. Before we speculate, let’s cover what was actually found. First, the target system is a line of TCL-branded smart TVs running Android. As many of us would, [sick codes] started with an NMAP scan, looking for open ports.

Fourteen. There were fourteen open ports, and not standard services, but semi-random high level ports. Most of them running HTTP/HTTPS services that are probably API connections of some sort. The most interesting port they found was 7978, where the entire root filesystem was available. That one got assigned CVE-2020-27403. A second vulnerability, CVE-2020-28055, is a folder permissions problem. The TCL vendor folder is world-writable, meaning that other apps could inject code there.

I managed to talk to [sick codes] himself about the issue, and he pointed out an app called TerminalManager_Remote as being particularly interesting. It seems to be a custom implementation of the TR-069 protocol, which is intended for remote management of ISP hardware. Why exactly that protocol is being used for smart televisions is unknown. One could speculate about how much information is being captured and sent back to TCL. At the very least, we can say that there is the potential for abusive behavior, given what we know about the software running on the unit.

There’s enough interesting elements to this story that I have ordered a TCL television, and plan to do some work on this topic myself. Keep an eye out for updates, and likely more CVEs to come.

Online Gaming and Security

I discovered a wonderful trio of articles by [Dan Petro] of Bishop Fox. He takes a look at the cheating issues in the world of online gaming, and which anti-cheat measures have worked and which haven’t, and then applies the lessons leaned to web application security. He makes the same observation that many of our readers have, the games industry has a weird love of using spyware for cheat prevention.

Article one is all about hidden information, and where the rules are actually enforced in a game. If the entire game map is sent to the clients, then it’s inevitable that a cheat can show the entire map to the player. Similarly, if the client is trusted to enforce game logic, then a client-side cheat can easily modify that logic. The obvious application is not to trust anything that runs on the user’s hardware. It’s far too easy to open the web console on a modern browser, and look closely at every bit of information that has been sent to the browser. Don’t trust the client.

Part Two is about detecting and banning bots. Aim-bots and macros are the two big problems in the gaming world. The preferred way to detect these is through “anomaly detection”. Is a certain gamer performing too many perfect inputs too quickly? Do they have a nearly impossible level of accuracy? You may recognize the similarity to Google’s reCAPTCHA program. In both cases, the system is looking for a “tell”, a giveaway that the user isn’t entirely human.

The last installment is all about race conditions. The example is how a player experiencing network lag seems to teleport around the map, and is impossible to hit. Some unscrupulous players went so far as to install a “lag switch” to intentionally trigger this behavior. The solution is using techniques like mutexes and enforcable syncronization rules to guarantee expected behavior. All told, the articles were an unexpected take on the philosophy of security, but a fun read.

Also on Tap

Earlier this week, Al Williams covered etherify. It’s a clever hack that uses an ethernet port as a makeshift transmission antenna.

Bryan Cockfield wrote up a clever attack against Ubuntu where a user could crash a system service, which fools the system into running the first-boot user creation dialogs again, allowing local priviledge escalation.