The Bug Report - March 2022

By Charles McFarland · April 6, 2022

Your Cybersecurity Comic Relief

Why am I here?

Welcome back the Bug Report, the more-bugs-than-bagels edition. Everyone could use a bagel but unfortunately, we are fresh out. No worries, we have a healthy serving of bugs as the main course for this month. For those unfamiliar with our report, every month we compile a short list of the top vulnerabilities of the month for your intellectual consumption. Sit back, relax and enjoy the cuisine.

This month there was no shortage of bugs to choose from as we March toward a bug free world! Of course, that’s never gonna happen but one may dream. The closet I’ve ever come to ‘bug free’ was when I once lived in a ladybug infested house in the country. True, they took care of all the other ‘bad’ bugs, but the ceiling was literally covered in red with black polka dots! I digress. March has some scary bugs for the Linux community as well as a couple being actively exploited by the bad guys. Let’s get to the March 2022 bug list so you can start your extermination!

• CVE-2022-0847: Linux Kernel (Dirty Pipe)
• CVE-2022-1096: Google Chromium V8 Engine
• CVE-2022-0543: Redis on Debian
• CVE-2022-24760: Node.js Parse Server module

CVE-2022-0847: Dirty Pipes need some cleaning….

What is it?

It seems that the most famous vulnerabilities get their own marketing team and catchy name. “Dirty Pipes” is one of the those but, given it’s a major Linux kernel bug, it’s well deserved. If was first reported by Max Kellerman in this report. He discovered something odd while dealing with their custom logging solution. After initially refusing to blame the OS (quite reasonably I might add), he eventually proved an arbitrary write error caused when the pipes code was refactored for Anonymous Pipes. The struct pip_buffer didn’t properly initialize one of the flags leaving it empty. This is a problem because it enables someone to create a page cache reference with an arbitrary flag. When Anonymous Pipes were refactored, you could then inject the PIPE_BUF_FLAG_CAN_MERGE flag on a cache reference. By shoving two things where only one belonged you can perform a write overflow of the page cache. Not only does this allow overwriting of arbitrary files, but it also works regardless of permissions and on immutable files!

Who cares?

I have some good news and some bad news. The good news is that this vulnerability only exists on devices with Linux Kernel 5.8 and higher. 5.16.11, 5.15.25, and 5.10.102 have addressed the vuln. Unless you’re actively upgrading your kernels manually or running bleeding edge distributions, you’re unlikely to see this on your servers or desktops. For example, the current Long-Term Support (LTS) version of Ubuntu server ships with kernel version 5.4 which isn’t vulnerable and other distributions such as RedHat are even further behind. Sometimes procrastination really does pay off!

The bad news is that many other important devices may be vulnerable and quite hard to find and potentially without available patches. While tempting to simply ignore anything you didn’t install yourself, you may want to pay attention this time. For example, many QNAP NAS devices are running the vulnerable kernel 5.10.60 with no patch yet available. Likewise, any device using Android 12 is also at risk including the Pixel 6 and Galaxy S22. It remains to be seen what other devices are affected. Since the 5.8 kernel was released in August 2020 only devices purchased since then should be cause for concern. That concern should only increase over time since POCs already exists within the original report and on Github.

What can I do?

Inventory your IOT devices and wait. It's been nearly a month and we’re still waiting on patches. A large part of the challenge will be finding what’s vulnerable so you can wait for the patch. We know a large number of QNAP devices are vulnerable and likely any device running Android 12, but it remains to be seen where else this may pop up.

CVE-2022-1096: Don’t Panic!

What is it?

Remember the Joo Janta 200 Super-Chromatic Peril Sensitive Sunglasses from The Hitchhiker’s Guide to the Galaxy? They keep the user from panicking by turning totally black at the first hint of trouble! That’s a lot like this Chromium bug. Little to no information is being released so we know it’s going to be bad. What little has been released points this to a type confusion issue in the V8 engine used by multiple browsers including Chrome 99.0.4844.84 for Window, Mac, and Linux as well as Microsoft Edge 99.0.1150.55. To make matters worse we know it’s being actively exploited in the wild. That’s enough for those glasses to go super opaque until all effected browsers can get their patches widely distributed.

Who cares?

I care, and you should too! Essentially, anyone with a modern-day browser should care. The two known impacted browsers are Chrome and Microsoft Edge, but many other chromium-based browsers may be impacted such as Opera. The declining Firefox base need not worry this time around as Firefox is not chromium-based. However, Chrome alone has 62.78% of the browser market as of February 2022 so most of you should be concerned. It’s unclear if non-browser apps powered by the V8 engine are susceptible. Many popular non-browser desktop apps use Electron which runs on the V8 engine. These should be watched closely, including VS Code, Slack, Discord, among many others.

What can I do?

Patch, patch, patch; that’s your mantra. Until we know more it’s difficult to say what could mitigate the exploits. Fortunately, both Chrome and Microsoft Edge already have patches available so you should enforce them in your environment.

CVE-2022-0543: Watch out for Muh Stick!

What is it?

I don’t really know how to pronounce Muhstik but in my head I only hear “My Stick”. I’m not sure how the botnet devs feel about that but considering they’re the bad guys I won’t lose sleep over it. Recently the infamous botnet has been seen targeting Redis servers with a Lua sandbox escape flaw CVE-2022-0543. While our Bug Report considers more than just CVSS metric, it does catch our attention when something scores a perfect 10 out of 10. While this isn’t entirely a March vulnerability as Debian released their security advisory mid-February, the inclusion of this vuln in the Muhstik botnet justifies overlooking a couple of weeks. The vulnerability exists because of the way Redis on Debian dynamically loads the Lua interpreter but fails to clear the package variable. In effect a package can be used to load the Lua libraries and execute trusted code on the system.

Who cares?

Redis is the most popular key-value database, the most popular NoSQL database in containers, and #4 for data store. There is a better-than-decent chance that one or more of your applications are running Redis. Further, Debian based deployments are especially common for servers and within containers. So, if you don’t wish to become a valued member of the Muhstik botnet and wish to avoid an uncomfortable meeting with the FBI, it’s best to check your services for the Redis/Debian pair.

What can I do?

If you haven’t applied your Debian update, then get to it. If you own your own containers, then update those as well. Otherwise, you’re at the mercy of whomever your container came from. If you’re too late, then it’s time to look for a botnet infection and purge it from existence.

CVE-2022-24760: Decidedly Not a Bagel

What is it?

If you’re in the ignorance-is-bliss camp and think databases are forever safer stop reading now. We don’t want you to be disappointed. Mid-March Github release a security advisory about a new Remote Command Injection vulnerability in the Parse Server 4.10.7 npm package and below. Like our new friend CVE-2022-0543 it has scary CVSS score of 10. This package affects Node.js powered webservers running the default MongoDB configuration (and maybe others). It’s a Prototype Pollution bug that impacts DatabaseController.js. Namely, by carefully crafting a HTTP request with the {_bsontype: “Code”} keyword an attacker can get Binary Encoded JavaScript Object Notation (BSON) code execution.

Who cares?

While I personally stay away from all things javascript, many of you love the language so much that you’ve decided it would make a great webserver backend. Who am I to judge? Node.js is used by powerhouses such as Netflix, PayPal, and the like. As of 2021 Node.js was powering over 28,000 websites and that doesn’t include other web servers. In short, it’s supposed to be publicly available so having an unauthenticated command injection just sitting there on the web is bad news.

What can I do?

First, you should be upgrading your Parse Server npm package to 4.10.7 or higher. That’s the recommended action. Sometimes in the development world updating packages may not be feasible right away. There is a workaround found here. In there you can apply some code that runs before Parse Server that handles the BSON code execution.