2

Free associating from 'df' to RCE

 2 years ago
source link: http://rachelbythebay.com/w/2022/06/16/rce/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

Free associating from 'df' to RCE

I like finding inspirations in unusual places. Several summers back, a friend shared a link to a story about apt-get starting Dwarf Fortress (!) when they tried to upgrade packages, or something like that. The general consensus was that it involved something intending to invoke df (as in /usr/bin/df, the command on the box) and getting the game instead of the "disk free" info. It was one of those things where you read about it and just groan, but you don't dig in because it's not biting you directly and you have your own problems.

I gave it my usual eyeroll because it fell squarely into the bucket of "running a subprocess to get info when a library call will do". It also had a bonus garnish of using something that looked in the PATH and so could be mislead into running the wrong thing somehow.

This chat lead to the inevitable topic of that time someone wrote an uninstaller that did something like "rm -rf $THING/", and sometimes $THING would be empty, so fun things happened. This generally put us in the mindset of "how can things go wrong", and "how can they can *be made* to go wrong, if you wanted to do that". The fact that a PATH was coming into play suggested system() or popen(), both of which run through a shell and thus introduce the possibility of injecting your own commands.

So there we were with a large corporate source tree sitting there in front of us. It contained lots of C++ and C code, besides other things. With all of the people writing code over the years, had anyone managed to make the same mistake? It wouldn't exactly be hard to grep it for popen, and so we did. Three minutes later, we found this "network helper" service that ran on the whole fleet, and what did it do?

FILE* output = popen(command.c_str(), "r");

Well, that's fun. What's this? It's listening to the network, and accepts RPCs? It'll run traceroute and ping for us? And it takes parameters like "destination"? So, all we had to do was find a host running it, fabricate a RPC with a destination including a little bonus, like "127.0.0.1; touch /tmp/0wned", and fire it off.

It happily ran touch and dropped the file in /tmp, thus proving we could get it to execute anything we wanted as that user. Oh yeah, and the file was owned by root, because this thing was running as root. Score! Root anywhere you want it!

With that, we now had a security incident to handle. On that particular day, the usual security peeps were busy some other thing that had broken early that morning. It turned out that this "feature" had been running in prod for a year, so letting it chill for a few more hours didn't change much. We let them put out that fire and then handed them the next flaming dumpster full of "win".

So, somehow, a share of a reddit post that linked to something on Ask Ubuntu turned into a way to get root on any machine in the company. That's the kind of free-association stuff that would happen. Good times.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK