Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 27 Sep 2014 21:15:12 +0200 (CEST)
From: Roman Drahtmueller <>
To:, Solar Designer <>
cc: Chester Ramey <>
Subject: Re: Fwd: Non-upstream patches for bash

> This also means that we should treat any programs that generate bash
> scripts with (sanitized) untrusted input in them as unsafe, and patch
> those to use safer mechanisms to pass (sanitized) inputs to scripts
> (preferably use env vars with fixed names).
> Comments?

The last 20 years were full of happiness, because people didn't know. A 
shell would only use what it is told to use, with the exception of some 
environment variables that are explicitly relevant for the shell and its 
mode of execution. It wouldn't matter if the environment contained a gig 
of stuff behind *envp, or garbage on stdin. The decision about trusting 
the execution environment must left up to the scripter.

Options for trust assumptions concerning the execution environment of a 
1) environment is completely untrusted.
2) environment contains variable names that are trusted
   - implicit: shell-relevant variables have trusted content
3) all of the environment is trusted (not our problem today)

about 1): The cause of CVE-2014-6271 and CVE-2014-7169 is not a parser 
problem, but a design problem. The fact alone that the parser runs - 
unconditionally, on potentially untrusted input - makes it most certainly 
not suitable for running with an untrusted environment (envp).

As a consequence (SD said that already), the environment in which the 
shell executes must contain variable names that are trusted (fixed) so 
that no interference can happen between untrusted input and stuff 
relevant for the shell. Those environment variables that determine 
execution parameters of the shell are unsafe to be inherited (not to 
mention parsed...):
--- Why do we have code that prevents inheriting IFS (20 years of silly 
    happiness, above), but then _PARSE_ others to even overwrite 
    $PATH-walk findings?


What the shell does (and how) needs to be seperate from what it deals 
with, or we give up on expecting deterministic results from a shell.
A trade-off could still be one (1!) variable with a static name that 
contains all exported functions, but not arbitrary ones.
Otherwise, go and help yourself with BASH_ENV if you need functions in 
subshells - and forget about parsing untrusted input at all.

> Alexander

A compatibility vs security debate is not really very productive. People 
have realized that the cause is a design question. If something breaks 
because broken design is flushed down the pipe, the response is much 
better than continuing to fix effects and not causes.


(*1) Apache's cgi interface (thoughtfully) sets variables as 
HTTP_${headername}, not ${headername}.

Roman Drahtmueller <>

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.