Thursday, June 26, 2014

Back To The Future: Unix Wildcards Gone Wild



On June, 25th 2014 DefenseCode released a whitepaper regarding a vulnerability
affecting all *nix derivatives:


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@defensecode.com>