Re: CERT/NIST reveal level 10 bash alert today, 24 September 2014

[Steve Simmons]

On Sep 25, 2014, at 5:42 PM, Alexandre FERRIEUX - SOFT/LAN 
<alexandre.ferrieux@orange.com> wrote:

> On 25/09/2014 22:51, Eric Blake wrote:
>> On 09/25/2014 08:48 AM, Alexandre Ferrieux wrote:
>>> Is the response (workarounds and patch) being discussed elsewhere ?
> 
> Thanks. Like thousands of people I guess, I have never imagined before today 
> that a "bash bug" could exist, so I'm new to this list, and did not realized 
> its archive was lagging a bit. Sorry about re-asking.
> 
>> 
>>> (2) Workaround
>>> 
>>> Privileged mode skips the import of functions from the environment, hence
>>> "#! /bin/bash -p" is a quick fix.
>>> I assume that 99.9% of uses would be unaffected by the other side-effects
>>> of -p.
>>> Am I missing something ?
>> Yes.  Among others, system(3) and popen(3) call /bin/sh, if /bin/sh is
>> bash, there is no way for you to pass -p into that child.
> Argh indeed.
> 
> Out of curiosity, may I ask what purpose 'export -f' serves ? In 20+ years of 
> unix (admittedly sticking to /bin/sh for lack of a compelling need of 
> anything else), I have never felt the need to share function across a 
> fork/exec (across a fork, of course, in subshells; but not a fork/exec). So 
> what is that use-case that motivated that tricky feature ?

Check the archive; there was just a long discussion on this and it should be in 
there by now. Look for the subject 'Issues with exported functions'.