Why BASH_FUNC_foobar%% Environment Variable Is Unset in Shell Subprocesses

bashenvironment-variables

I'm messing around with the security of a setuid binary (with the intention of disclosing anything I find to the author, obviously). I'm pretty sure it has an arbitrary code execution vulnerability because it invokes a shell script and it doesn't sanitize the environment – I thought of bash's export -f but I can't actually make a proof of concept work.

The basic problem is that for some reason, BASH_FUNC_foobar%% (where foobar is the function being exported) is mysteriously vanishing from the environment in some subprocesses. It works with non-shells:

% env 'BASH_FUNC_foobar%%=() { echo pwd lol; }' env | grep BASH
BASH_FUNC_foobar%%=() { echo pwd lol; }

But if I replace env | grep BASH with the actual program name, modified to dump the environment (basically just system("env") in the C source), this variable is removed. The same happens when I specify sh as the command to invoke, although weirdly enough, if I specify bash then the function is picked up just fine.

Note that on my test system /bin/sh is provided by dash.

What the heck is going on? Why is this variable disappearing?

Best Answer

On many linux systems, /bin/sh is actually /bin/dash.

As already mentioned in a comment by @MichaelHomer /bin/dash will sanitize the environment and remove from it any strings which are not of the form /^[a-zA-Z_][a-zA-Z_0-9]*=.*/, and that includes the BASH_FUNC_foo%%=..., because of the %%.

This is quite specific to dash and to OpenBSD's ksh (and mksh which is based on it) -- other shells won't bother to do that.

Example, on debian where /bin/sh is dash:

$ env - '@#%=' 'foo%%=bar' /bin/sh -c /usr/bin/printenv
PWD=/your/cwd
$ env - '@#%=' 'foo%%=bar' /usr/bin/printenv
@#%=
foo%%=bar
$ env - '@#%=' 'foo%%=bar' /bin/bash -c /usr/bin/printenv
[...]
@#%=
foo%%=bar

For a source reference you can look at src/var.c in the dash source:

    initvar();
    for (envp = environ ; *envp ; envp++) {
            p = endofname(*envp);
            if (p != *envp && *p == '=') {
                    setvareq(*envp, VEXPORT|VTEXTFIXED);
            }
    }

When dash exec's another binary, the env argument passed to execve is built from the variable list dynamically (with listvars(VEXPORT, VUNSET, 0) as called via the environment() macro).

Related Solutions

Bash Variables – Difference Between Environment Variable and Shell Variable

Your second assignment TEST="SHELL_TEST" doesn't un-export the variable. It's still marked as "to be inherited by children". And the value inherited by the child is the value currently set in the parent.
In other words, your second assignment doesn't revert the status of TEST to a shell variable, it's still an environment variable according to that terminology.

You'd have to un-export it for it to become unset in children processes:

$ typeset +x TEST
$ sh -c 'echo $TEST'

$

Setting user environment variable permanently, outside shell

If all the shells you're interested in are Bourne-compatible, you can use /etc/profile for this purpose.

The header of /etc/profile:

# /etc/profile: system-wide .profile file for the Bourne shell (sh(1))
# and Bourne compatible shells (bash(1), ksh(1), ash(1), ...)

To ensure you've got csh and tcsh covered, you can also add your variables to /etc/csh.login.

The header of /etc/csh.login:

# /etc/csh.login: system-wide .login file for csh(1) and tcsh(1)

For zsh, you want /etc/zshenv.

For ease of maintenance

I would write all the variables you want in a single file and write a simple Perl (or other) script that would read these variables and update the relevant files for all the shells.

Something like the following in Perl should work:

 #!/usr/bin/perl

use strict;
use warnings;

my $bourne_file = '/etc/profile';
my $csh_file = '/etc/csh.login';
my $zsh_file = '/etc/zshenv';
open my $BOURNE,'>>', $bourne_file;
open my $CSH,'>>', $csh_file;
open my $ZSH,'>>', $zsh_file;
while(<DATA>){
    chomp;
    my $delimiter = ','; #Change , to whatever delimiter you use in the file

    my ($var, @value) = split /$delimiter/;        
    my $value = join $delimiter,@value;
    print $BOURNE qq{export $var="$value"\n};
    print $CSH    qq{setenv $var "$value"\n};
    print $ZSH    qq{export $var="$value"\n};
}
close $BOURNE;
close $CSH;
close $ZSH;
__DATA__
var1,val1
var2,val2

You can use a delimiter other than , to delimit variables and values as long as this delimiter isn't allowed in variable names.

This can be further tidied up by inserting unique delimiters around the portion you want your script to write in each file so that each time you use the script to update the files, it doesn't duplicate previous entries but substitutes them in situ.

Best Answer

Related Solutions

Bash Variables – Difference Between Environment Variable and Shell Variable

Setting user environment variable permanently, outside shell

Related Question