Linux Zero Day: JournalCtl and Syslog Terminal Escape Injection

Every week, Stephen Coty writes about interesting exploits that have caught his attention as chief security evangelist at Alert Logic. This last week (in a currently password protected posting) he mused about a 'JournalCtl and Syslog Terminal Escape Injection' zero day which could be of interest to the Linux gurus here on DaniWeb.

Here's the story. A new init control system called Systemd is being integrated into Linux distros, in an effort to update and overhaul SysV and upstart so as to become a more modern init system. Fedora has already jumped into Systemd, and as I understand it Ubuntu won't be far behind.

What has caught the attention of the security researchers at Alert Logic, however, is that the Systemd architecture uses a log management architecture called journal which uses journalctl to read the binary data represented in the journals. Which is where things get interesting, Coty says, as journal has the ability to read ‘unprintable’ characters.

Without the use of the right flags, messages with unprintable characters are referenced as binary blobs and Journalctl fully allows terminal escape characters to be represented (while the older syslog system filters these out) and so opens up an injection risk.

Coty tells me that if we were to inject something like echo -e “\e]2;WINDOW HIJACK\a” then it would be possible to hijack the title bar of the tab or terminal window.

"All we need to do is be able to find daemons, locally or remote, that allows a user controlled injection to be placed into a debug log" Coty says, adding "Locally this can easily be done with CUPS as it uses unfiltered getenv everywhere and remotely this can be done with avahi packet parsing error messages."

Of course, there is a problem here which you've probably already spotted: how do you get those debug logs in order to get into the journaling system? Coty answers with Syslog as most daemons implement debugging functions, but they are written to mainly integrate with Syslog. "Until we see more journal adoption, we need syslog to still be on the system to pass the debug messages to the journal" Coty insists as when both are in play then journalctl can be used to inject. Coty advises that as the injection capability relies on the terminal emulator being used, currently Gnome-terminal is the easiest to use to inject arbitrary command execution, and xterm the most secure.

So, what do the DaniWeb Linux gurus make of all this?

[mike_2000_17]

In view of the latest head-butting between Linus Torvalds (head of Linux) and Kay Sievers (head of Systemd), this looks to be related. Apparently, systemd has had a long history of ignoring bugs and forcing others to work around their quirky or sub-standard software. The fact that it doesn't strictly filter logs seems to be inline with that reputation. I would assume that in any seriously maintained software projects, such trivial vulnerabilities would be patched up (up-stream and down) as soon as it's discovered.

I recently went through the exercise of compiling the Linux kernel from source for a ARM board. Systemd was one of those components that was constantly giving problems along the way, but in all fairness, it's pretty central too. This project should be handle with double the rigor of any other project, but instead, it seems to get about half the rigor of other projects.

[Hiroshe]

Though it's not alarming in practice (I wouldn't go as far as to avoid an update to something using Systemd), it should be fixed somewhere along the line, preferable within Systemd itself.

It doesn't sound too hard to fix either. A patch preventing escape characters could easily be made ad-hoc by the vendor if it must.

[turboborland]

Well...my name is Tyler Borland (TurboBorland) and I wrote this (and all the exploit monday stuff that's getting leaked) and didn't expect Coty to leak it out, that's why I password protected it to prevent more caching.

The vulnerability itself isn't that severe considering you have to use the appropriate flags when reading the journal binary file. Some other implementations could be more interesting like remote logging software. It was just fun bringing back old bugs with new implementations.

As for injection, there's a lot of projects that use unrestricted (secure_)getenv in a default system and, for remote, there's some projects that have error messages from local network traffic that get logged.

Now, the reason gnome-terminal is more interesting is because there's lots of things you can do with the VT sets it supports. Where xterm is minimal without iconify. You can check the system's support by dumping the termcaps with tools like tic/toe/infocmp for each. The whole window title change is supported by everything and it's simple, which is why it's a good PoC, but more can be done depending on situation and the terminal's supported termcaps.

[turboborland]

Alright guys, because this was posted here I added some new information available and posted an updated version on my blog:

turbochaos.blogspot.com/2014/08/journalctl-terminal-escape-injection.html

I have provided a python script that allows someone to inject messages directly into Journal by using the UNIX socket (srw-rw-rw-. 1 root root). By changing argv[0] we can also pretend to be another process's message as long as -o=verbose isn't on to check for full path of binary. Enjoy.

[happygeek]

Just to clarify, I was sent the information about the vulnerability along with all the detail as a potential news story by the PR company acting for Alert Logic. There was no 'leak' as far as I was aware, it was just another in a long line of communications from PR companies and security vendors/researchers that I get on a daily basis in my job as a tech journalist specialising in IT security. The difference with this one, compared to many, being that I thought it would be of interest to the DaniWeb Linux commuunity.

[Chris_22]

Systemd is designed to become central to the systems using it. It is, however, in no way central to Linux in general. There are sysvinit, BSD init, upstart, daemontools, OpenRC, and more which can be used.

Perhaps if the quality of this software is so low it's not worth using. It's already going against the modularity and plain text logging ideals so long part of Unix culture.

[rubberman]

There is a lot of noise about systemd's faults all over the net. I've been in a discussion on the LinkedIn Linux Experts group about this very topic. Honestly, in many regards it is a hacked design for such a system-critical component (no formal methodology, modeling, verification, etc.) and many of us are of the opinion this is going to become a serious problem instead of the solution it purports to be. If I were Linus, I would be butting heads also!