BACK TO THE FUTURE: UNIX WILDCARDS GONE WILD

On June, 25th 2014 DefenseCode released a whitepaper regarding a vulnerability

affecting all *nix derivatives:

http://www.defensecode.com/public/DefenseCode_Unix_WildCards_Gone_Wild.txt

Basically, this bug allows a user to affect shell commands issued by some other user by creating files with special filenames. If the other user is a privileged user like root this would theoretically lead to an elevation of privileges aka “local root” or “local privilege elevation”. The paper contains some basic examples for different unix commands and their impact if used in combination with wildcards.

At a first blush, the vulnerability does not seem to be very critical. It looks like that it would only affect shell scripts badly coded and afterwards executed by some higher privileged user.

But if you dig a little bit deeper and think about all the different *nix operating systems, their boot- and shutdown-sequences and their local servers running with high privileges, one will realize very fast, that this vulnerability has a huge security impact on most unix like operating systems. This bug affects Android, iOS, OS X and all the embedded solutions running on Linux. In addition to this you have Oracle, RedHat and other commercial Linux based systems. Many of these operating systems have different shell utilities and tools accepting even more command line options. A short check on Ubuntu gave us at least 5 commands, besides the ones mentioned in the whitepaper, vulnerable to this specific problem.

In addition to this you have to imagine Cloud service- or web hosting providers running cron jobs for backups and similar tasks of their users’ data.

This bug has a very high potential when further analyzed. Since this bug originates from a design problem it will be very interesting on how operating system vendors address this problem. It is something you cannot fix with a simple patch. The way on how the system interacts with files has to be completely redesigned.

Credits for identifying those issues go to Leon Juranic <leon(at)defensecode.com>