Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 25 Sep 2014 17:20:12 +0100
From: Simon McVittie <>
Subject: Re: CVE-2014-6271: remote code execution through bash

On 25/09/14 16:59, John Haxby wrote:
> I'm sure that there are going to be chains of exploits where each
> program in the chain doesn't believe that it needs a whitelist.
> For example, suid program A doesn't need a whitelist because it doesn't
> go anywhere near a shell, the closest it gets is exec'ing one of a
> well-defined set of programs ...

If those programs are not specifically designed to be a privilege
boundary, and suid program A is, then in my opinion, it is a serious bug
for suid program A to execute them in an attacker-controlled environment.

> ... one of which is written in python (say)

This nicely proves my point, actually. You've already lost, assuming the
Python program imports the standard library's "os" module (in practice
it will). No need for any bash subtleties:

    echo "__import__('subprocess').call(['/bin/sh'])" > ./
    PYTHONPATH=`pwd` suid-program-A

(Any standard library module not built into the Python executable would
do nicely, "os" is just an example that's likely to work.)

> There are lots of things one could do to eliminate that risk, of course,
> but step back and what are we arguing for?

I'm arguing that privilege boundaries should take responsibility for
their nature as a privilege boundary, and not pass the buck to the code
that they call into.


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.