STE WILLIAMS

A pair of recent bugs in a very widely used Linux system tool called systemd have just been “weaponised” by a US cybersecurity company called Capsule8.

The systemd project is a large, complex and popular – but also controversial – toolkit used by many mainstream Linux distros to handle system startup and logging.

The -d at the end of the name denotes that it’s a daemon, the Unix/Linux version of what Windows calls a service.

In other words, it loads like a regular app – in fact, a daemon is a regular app – but then eases itself into the background where it keeps running even when no one is logged in.

Because systemd is typically the “mother of all processes” on a Linux computer – in technical terms, it has the process ID 1 – many of its components run as root so that they have the administrative authority needed to take charge of the system.

If your Linux system were a game of chess, the kernel would be your King, and systemd would be your Queen.

To put it mildly, bugs in systemd typically matter quite a lot.

On a stripped-down server, system startup is often surprisingly simple, not least because less is more when it comes to security.

After all, features such as Bluetooth connectivity, touch pad operation, graphics acceleration, multiscreen support, sound, battery life and hibernation are unimportant on most servers.

But for desktop and laptop users, all these things matter enormously – fast bootup and super-quick ‘wake from sleep’ are highly desirable these days.

Tackling the convoluted startup complexities of a modern Linux desktop was part of the inspiration for systemd, and is one of the things that helped to make it popular.

At the same time, this led to convoluted complexities in systemd itself, which has made it controversial with a vocal minority in the Linux community.

After all, greater complexity means more to go wrong, something that’s a really serious issue for servers, where the do-it-all-and-do-it-fast feature set aimed at Linux desktop users is, ironically, less relevant.

Anyway, a trio of long-standing bugs in systemd were uncovered and reported by security researchers at Qualys at the end of 2018.

The bugs were documented in some detail early in January 2019, and should be patched by now in any mainstream Linux distro that incorporates the systemd code.

No BSD-derived operating system, including macOS, uses systemd. Many Linux-based IoT devices avoid it on account of its complexity, and various Linux distros, primarily those that are focused on simplicity or security, use alternative startup systems instead. Check your distro for details. Well-known Linuxes that don’t have systemd, at least by default, include Alpine, Gentoo and Slackware.

We shan’t go into the details of the vulnerabilities and exactly why and how they are exploitable, but we will use this story as a reminder of how security bugs can often be exploited in pairs.

Smashing the stack

CVE-2018-16865, one of the bugs in this trio, is triggered by code in systemd‘s logging software that allocates temporary memory without first checking that the request is of a sensible size.

If you’re writing an entry to the system log, it’s reasonable to send a line of text, or even a few kilobytes of diagnostic data, but this bug means you can throw gigabytes of data at the logging process…

…and it will try to allocate a dangerously vast amount of temporary storage on the stack.

As you can imagine, an overflow on the stack, where critical data such as software return addresses and system memory pointers are stored, is always going to mean trouble.

Crash on demand

Qualys quickly figured out how to use jumbo-sized log messages to redirect program execution where it didn’t belong.

However, in modern Linux distros, the widespread use of ASLR, short for Address Space Layout Randomisation, means that system software is automatically loaded at different locations in memory every time you reboot.

Many attacks require not only that you sneak unauthorised data into memory, but also that you guess in advance where it will end up, so you know where to mis-direct the flow of execution.

As a result of ASLR, therefore, it’s difficult to use a bug like CVE-2018-16865 on its own to take control of someone else’s server.

Smashing the stack often makes it easy to divert program execution, but if you can’t control where your diversion ends up, you generally crash the program you’re attacking instead of taking it over.

You can think of stack smashing on a system protected by ASLR as being like blindly and suddenly turning left (by which we mean right in the USA) while you’re driving though town.

Maybe, just maybe, you’ll end up turning safely into an actual side-street, but even if you do, you won’t have any idea where you’re going next – and you’ll probably rear-end a parked car anyway.

Much more likely is that if you make a blind turn, you’ll instantly end up in a ditch, T-bone a bus stop, plunge into someone’s front garden, or smash through a window into an unfortunate shop.

Controlling the crash

But there’s another bug in the trio, CVE-2018-16586, whereby you can send sneakily-formatted text to the system log that causes systemd to write out a message containing data from parts of memory that you aren’t supposed to see – a data leakage flaw often referred to as an information disclosure vulnerability.

By choosing your booby-trapped message carefully you can trick the logger into printing a message that gives away the memory address where various attack-friendly pieces of system code can be found.

In other words, by triggering CVE-2018-16856 first, you can find out the details of memory addresses that are supposed to be hidden due to the randomisation in ASLR.

Once you’ve done that, you can trigger CVE-2018-16585 with enough advance information to control the crash and achieve what’s known as remote code execution.

What to do?

With basic exploit code now openly published, even hackers who aren’t very technical have a good place to start.

So, if your Linux distro uses systemd, check that your distro has these holes patched…

…and that you’ve installed the relevant updates!

---

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/9VcYAqygmvQ/