Re: Bug#762839: bash without importing shell functions from the environment

[Henrique de Moraes Holschuh]

On Tue, 30 Sep 2014, Thorsten Glaser wrote:
> On Fri, 26 Sep 2014, Matthias Urlichs wrote:
> > In any case, adding "-p" to any #!/bin/bash shebang line looks like a very
> > good idea. Shall we add a Lintian check for this?
> 
> ***ABSOLUTELY NOT***
> 
> The -p option is for the shell to *not* drop privileges when
> called setuid.

Agreed.  Better to come up with a new command line flag.  And this needs to
be done upstream in the first place.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140930104334.ga10...@khazad-dum.debian.net

Re: Bug#762839: bash without importing shell functions from the environment

[Matthias Urlichs]

Hi,

Thorsten Glaser:
> On Fri, 26 Sep 2014, Matthias Urlichs wrote:
> 
> > In any case, adding "-p" to any #!/bin/bash shebang line looks like a very
> > good idea. Shall we add a Lintian check for this?
> 
> ***ABSOLUTELY NOT***
> 
> The -p option is for the shell to *not* drop privileges when
> called setuid.

Yes, it does that. It _also_ does all the other sanity-preserving things a
shell started in an insecure environment should do.

IMHO, code which calls a shell script with euid != ruid is buggy anyway,
because it _cannot_ depend on the shell to pro-actively fix that omission.
Any other program which happens to not be a #!/bin/bash shell script,
started the same way, will not reset its euid either. I don't expect any
other shell to care; the dash(1) manpage implies that it does not, for
instance.

Therefore I do not think that adding this flag would create any new
security problems.

Feel free to find a real-world counterexample.

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140930095719.ge7...@smurf.noris.de

Re: Bug#762839: bash without importing shell functions from the environment

[Thorsten Glaser]

On Fri, 26 Sep 2014, Matthias Urlichs wrote:

> In any case, adding "-p" to any #!/bin/bash shebang line looks like a very
> good idea. Shall we add a Lintian check for this?

***ABSOLUTELY NOT***

The -p option is for the shell to *not* drop privileges when
called setuid.

bye,
//mirabilos
-- 
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font.   -- Rob Pike in "Notes on Programming in C"


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1409301056180.20...@tglase.lan.tarent.de

Re: Bug#762839: bash without importing shell functions from the environment

[Matthias Urlichs]

Hi,

Raphael Geissert:
> On Friday 26 September 2014 18:48:37 Matthias Urlichs wrote:
> [...]
> > In any case, adding "-p" to any #!/bin/bash shebang line looks like a very
> > good idea. Shall we add a Lintian check for this?
> 
> No.
> 
… and why not? 

Importing random functions from the environment is a misfeature which will
bite us again in the future.

The alternate solution is to disable this code entirely. Fine with me;
I seriously doubt that anybody needs this code, let alone would notice.

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: Re: Bug#762839: bash without importing shell functions from the environment

[Raphael Geissert]

On Friday 26 September 2014 18:48:37 Matthias Urlichs wrote:
[...]
> In any case, adding "-p" to any #!/bin/bash shebang line looks like a very
> good idea. Shall we add a Lintian check for this?

No.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/3357630.pKJCJujf7X@eee

Re: Bug#762839: bash without importing shell functions from the environment

[Matthias Urlichs]

Hi,

shawn wilson:
> > Maybe we should add the patched version, with an appropriate NEWS entry,
> > to backports?
> >
> 
> Maybe?

"Maybe we" as a shorthand for "IMHO, the maintainer of bash should".

Better? :-)

Also, '-p' (privileged mode, i.e. ignore functions in the environment, as
well as a bunch of special envvars which change bash's behavior in
interesting ways) should really be the default for scripts; I suspect that
nothing whatsoever would break if non-interactive shells had that flag set
forcibly.

In any case, adding "-p" to any #!/bin/bash shebang line looks like a very
good idea. Shall we add a Lintian check for this?

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: Bug#762839: bash without importing shell functions from the environment

[shawn wilson]

On Sep 25, 2014 3:18 PM, "Matthias Urlichs"  wrote:
>
> Hi,
>
> Samuel Thibault:
> > Sounds crazy to me.
> >
> Definitely. This is now out in the wild; exploits which simply replace
> echo or cat-without-/bin are going to happen. :-/
>

Actually, what I've seen reported in the wild have been wget and run an irc
cnc script.a

> Maybe we should add the patched version, with an appropriate NEWS entry,
> to backports?
>

Maybe?

Re: Bug#762839: bash without importing shell functions from the environment

[Vincent Lefevre]

On 2014-09-26 10:33:20 +0200, Josselin Mouette wrote:
> Brian May  wrote: 
> No, I don't think that is the case. I believe sudo interprets
> those assignments itself (as also shown in man page), and  the
> error I got clearly shows this to be the case.
> 
> brian@aquitard:~$ sudo echo='() { /bin/echo bar; id; }'
>  ./test.sh
> sudo: sorry, you are not allowed to set the following
> environment variables: echo
> 
> My understanding is that sudo doesn't invoke any sort of shell
> unless you expressly tell it to do so.
> 
> 
> Does it also apply to variables that are part of env_keep in sudo?
> For example if you set TZ, PS1 or XAUTHORITY, which are preserved by
> default.

I'm not sure I understand your question. With CVE-2014-6271 fixed,
there are no problems, except for scripts that invoke TZ, PS1 or
XAUTHORITY as commands. This is rather unlikely, since commands
with uppercase letters are not so common (I just know GET, HEAD,
POST, and X).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140926085325.gb2...@xvii.vinc17.org

Re: Bug#762839: bash without importing shell functions from the environment

[Vincent Lefevre]

On 2014-09-26 09:19:17 +0200, Samuel Thibault wrote:
> Nikolaus Rath, le Thu 25 Sep 2014 17:26:40 -0700, a écrit :
> > Wasn't there some web server that used to put query script variables
> > into the environment of the CGI script?
> 
> Well, that ought to have been fixed a long time ago already,
> otherwise you could have injected all sorts of LD_*.

It depends on the environment variable names. Names with lowercase
characters, such as "exec", are safe, since for application usage
only[*]. Well... actually not with bash!

[*] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140926083248.ga2...@xvii.vinc17.org

Re: Bug#762839: bash without importing shell functions from the environment

[Josselin Mouette]

Brian May  wrote: 

On 26 September 2014 14:15, Russ Allbery  wrote:

That would surprise me.  In one case, you're setting an
environment
variable and then running sudo.  In the other case,
you're telling sudo to
run the command "echo='() { /bin/echo bar; }' echo foo"
via a shell. 


No, I don't think that is the case. I believe sudo interprets
those assignments itself (as also shown in man page), and  the
error I got clearly shows this to be the case.

brian@aquitard:~$ sudo echo='() { /bin/echo bar; id; }'
 ./test.sh
sudo: sorry, you are not allowed to set the following
environment variables: echo

My understanding is that sudo doesn't invoke any sort of shell
unless you expressly tell it to do so.


Does it also apply to variables that are part of env_keep in sudo?
For example if you set TZ, PS1 or XAUTHORITY, which are preserved by
default.
-- 
Joss 

Re: Bug#762839: bash without importing shell functions from the environment

[Samuel Thibault]

Brian May, le Fri 26 Sep 2014 11:40:00 +1000, a écrit :
> On 26 September 2014 10:26, Nikolaus Rath <[1]nikol...@rath.org> wrote:
> 
> Wasn't there some web server that used to put query script variables
> into the environment of the CGI script? Or am I confusing that with
> PHP's evil register_globals?
> 
> 
> CGI is just one avenue for attack.
> 
> There are other avenues. e.g. the ssh one, if I understand correctly, would
> allow setting any environment variable to any value.

No, it only allows what was explicitly listed in AcceptEnv.

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140926072117.gk3...@type.youpi.perso.aquilenet.fr

Re: Bug#762839: bash without importing shell functions from the environment

[Samuel Thibault]

Nikolaus Rath, le Thu 25 Sep 2014 17:26:40 -0700, a écrit :
> Samuel Thibault  writes:
> > Matthias Urlichs, le Thu 25 Sep 2014 21:17:58 +0200, a écrit :
> >> Samuel Thibault:
> >> > Sounds crazy to me.
> >> > 
> >> Definitely. This is now out in the wild; exploits which simply replace
> >> echo or cat-without-/bin are going to happen. :-/
> >
> > That's not so easy to exploit. You have to manage to inject those precise
> > variable names.
> 
> Wasn't there some web server that used to put query script variables
> into the environment of the CGI script?

Well, that ought to have been fixed a long time ago already, otherwise you could
have injected all sorts of LD_*.

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140926071917.gj3...@type.youpi.perso.aquilenet.fr

Re: Bug#762839: bash without importing shell functions from the environment

[Matthias Urlichs]

Hi,

Martin Uecker:
> While everybody is looking at bash, isn't this the real the
> injection part? Why are there still programs which copy stuff
> from the network into environment without proper sanitation? 

Probably either sheer laziness, or for the usual, misguided-these-days
(IMHO) "be lenient in what you accept" reason.

In any case, there are a bunch of crazy URL schemes out there,
so who are you to decide that PATH_TRANSLATED="() {:;};rm -rf $(ls /)"
is unreasonable? Literally all of these characters occur in actual
real-world URLs, and RFC 3875 explicitly says that it may contain "any
character".

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: Bug#762839: bash without importing shell functions from the environment

[Russ Allbery]

Brian May  writes:

> No, I don't think that is the case. I believe sudo interprets those
> assignments itself (as also shown in man page), and the error I got
> clearly shows this to be the case.

> brian@aquitard:~$ sudo echo='() { /bin/echo bar; id; }'  ./test.sh
> sudo: sorry, you are not allowed to set the following environment
> variables: echo

Ah!  You're right.  I totally missed that capability of sudo.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87eguzng2z@hope.eyrie.org

Re: Bug#762839: bash without importing shell functions from the environment

[Mike Hommey]

On Fri, Sep 26, 2014 at 01:37:48PM +1000, Brian May wrote:
> On 26 September 2014 12:08, Russ Allbery  wrote:
> >
> > > brian@aquitard:~$ sudo echo='() { /bin/echo bar; }'  bash
> > > root@aquitard:/home/brian# echo hello
> > > bar
> >
> > I think you have that backwards, don't you?  Shouldn't that be:
> >
> > echo='() { /bin/echo bar; }' sudo bash
> >
> 
> I think sudo treats both as the same/similar thing.
> 
> However, just edited /etc/sudoers and replaced:
> 
> %sudo  ALL=(ALL:ALL) ALL
> 
> with:
> 
> %sudo ALL = (ALL:ALL) /home/brian/test.sh
> 
> i.e. lets me run only that specific command, and now sudo does sanitize the
> environment:
> 
> brian@aquitard:~$ sudo echo='() { /bin/echo bar; id; }'  ./test.sh
> sudo: sorry, you are not allowed to set the following environment
> variables: echo
> 
> 
> sudo should stop you from doing things like this unless you've explicitly
> > told sudo to allow the client to set any environment variable.
> >
> 
> Seems to be it is disabled if you allow the client to run any command too.
> 
> However, forget my concern for sudo, it doesn't exist.

Note that bash itself has /some/ protection, according to bash -c 'help
set':

  -p  Turned on whenever the real and effective user ids do not match.
  Disables processing of the $ENV file and importing of shell
  functions.  Turning this option off causes the effective uid and
  gid to be set to the real uid and gid.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140926043721.ga10...@glandium.org

Re: Bug#762839: bash without importing shell functions from the environment

[Brian May]

On 26 September 2014 14:15, Russ Allbery  wrote:

> That would surprise me.  In one case, you're setting an environment
> variable and then running sudo.  In the other case, you're telling sudo to
> run the command "echo='() { /bin/echo bar; }' echo foo" via a shell.
>
> No, I don't think that is the case. I believe sudo interprets those
assignments itself (as also shown in man page), and  the error I got
clearly shows this to be the case.

brian@aquitard:~$ sudo echo='() { /bin/echo bar; id; }'  ./test.sh
sudo: sorry, you are not allowed to set the following environment
variables: echo

My understanding is that sudo doesn't invoke any sort of shell unless you
expressly tell it to do so.

aquitard# strace -ff -eprocess sudo A=B date
execve("/usr/bin/sudo", ["sudo", "A=B", "date"], [/* 21 vars */]) = 0
arch_prctl(ARCH_SET_FS, 0x7fc58a68b7a0) = 0
clone(Process 25854 attached (waiting for parent)
Process 25854 resumed (parent 25853 ready)
child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x7fc58a68ba70) = 25854
[pid 25854] execve("/bin/date", ["date"], [/* 18 vars */]) = 0
[pid 25854] arch_prctl(ARCH_SET_FS, 0x7fef50d2c700) = 0
Friday 26 September  14:27:51 EST 2014
[pid 25854] exit_group(0)   = ?
Process 25854 detached
--- SIGCHLD (Child exited) @ 0 (0) ---
wait4(25854, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WNOHANG|WSTOPPED,
NULL) = 25854
exit_group(0)   = ?

-- 
Brian May 

Re: Bug#762839: bash without importing shell functions from the environment

[Russ Allbery]

Brian May  writes:
> On 26 September 2014 12:08, Russ Allbery  wrote:
>>
>> I think you have that backwards, don't you?  Shouldn't that be:
>>
>> echo='() { /bin/echo bar; }' sudo bash

> I think sudo treats both as the same/similar thing.

That would surprise me.  In one case, you're setting an environment
variable and then running sudo.  In the other case, you're telling sudo to
run the command "echo='() { /bin/echo bar; }' echo foo" via a shell.  In
other words, with your original command, the actual command that you're
running with sudo is probably something like:

/bin/bash -e "echo='() { /bin/echo bar; }' echo foo"

and sudo itself never sees your environment setting.

sudo controls whether it's willing to pass arbitrary environment variables
to the command it runs with the env_reset, env_keep, and env_check
options.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87tx3vnhjm@hope.eyrie.org

Re: Bug#762839: bash without importing shell functions from the environment

[Brian May]

On 26 September 2014 12:08, Russ Allbery  wrote:
>
> > brian@aquitard:~$ sudo echo='() { /bin/echo bar; }'  bash
> > root@aquitard:/home/brian# echo hello
> > bar
>
> I think you have that backwards, don't you?  Shouldn't that be:
>
> echo='() { /bin/echo bar; }' sudo bash
>

I think sudo treats both as the same/similar thing.

However, just edited /etc/sudoers and replaced:

%sudo  ALL=(ALL:ALL) ALL

with:

%sudo ALL = (ALL:ALL) /home/brian/test.sh

i.e. lets me run only that specific command, and now sudo does sanitize the
environment:

brian@aquitard:~$ sudo echo='() { /bin/echo bar; id; }'  ./test.sh
sudo: sorry, you are not allowed to set the following environment
variables: echo


sudo should stop you from doing things like this unless you've explicitly
> told sudo to allow the client to set any environment variable.
>

Seems to be it is disabled if you allow the client to run any command too.

However, forget my concern for sudo, it doesn't exist.
-- 
Brian May 

Re: Bug#762839: bash without importing shell functions from the environment

[Mike Hommey]

On Thu, Sep 25, 2014 at 04:29:05PM +0100, Ian Jackson wrote:
> Package: bash
> Version: 4.1-3
> 
> I have prepared bash packages which do not honour any shell functions
> they find in the environment.  IMO that is a crazy feature, which
> ought to be disabled.  (I'm running this on chiark now and nothing has
> visibly broken yet.)
> 
> Packages (i386) for squeeze, wheezy and sid are here:
>   http://www.chiark.greenend.org.uk/~ian/bash-noshellfunctions/
> 
> dgit format git branches are here:
>   git://git.chiark.greenend.org.uk/~ianmdlvl/bash.git
>   http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git/bash.git/
> 
> A codesearch [1] shows that this change will break very few things.
> Arguably we (Debian) should apply this in sid (hence this bug report).
> Doing it in security updates to stable releases is sadly too risky.
> But people who want to take that risk themselves are welcome to
> install my packages.
> 
> (It took me merely a few moments with the source code to prepare the
> code patch.  But then I had to spend an hour or two wrestling with the
> patch systems of the packages in squeeze and wheezy.  I would like to
> take this opportunity to say how much I appreciate the work of the
> security team, who have to cope on a daily basis with [CoC violation]
> such as that found in the squeeze and wheezy bash Debian `source'
> packages.)

Note that an upstreamable change would be to, at the very least, disable
it in posix mode (the one you get when running bash as sh), since
export -f is, after all, a bashism.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140926030040.ga20...@glandium.org

Re: Re: Bug#762839: bash without importing shell functions from the environment

[Martin Uecker]

Russ Allbery :
> Martin Uecker  writes:
>
> > While everybody is looking at bash, isn't this the real the injection
> > part? Why are there still programs which copy stuff from the network
> > into environment without proper sanitation?
> 
> The previous sanitization for environment variables mostly focused on not
> letting the client set arbitrary environment variables and instead tightly
> restricting which variables could be set.  The problem with this
> vulnerability is that the varible doesn't matter, only the value, which is
> a new type of problem.

See the link I posted. This was about shell escaping and fixed
with sanitization of the content in dhclient. But for some reason
it seems it was not applied to all variables, which would have
prevented the present problem for dhcp.

> Also, prior to the discovery of this bug, I'm dubious that anyone would
> have found this particular environment variable pattern all that
> concerning.  It's not obvious why it would be an issue.  So only a pure
> whitelisting approach on environment variable *contents* would have been
> effective, and it's hard to define what language you want to restrict the
> contents to.

Yes, it is a bit difficult to decide what is acceptable and what
not. But environment variables are a huge attack surface because
they are passed on and you have to garantuee that no child process
does something stupid. E.g. some process may dump its complete
environment into a log file and have a buffer overrun there...
Does not seem unlikely to me.

> It's very useful in some web situations to get access to arbitrary
> client data via environment variables. I sometimes want *exactly* what the 
> client sent as its Browser string, for instance, metacharacters and all.
> I should be able to get that as an environment variable and process it;
> there's no obvious reason to believe that should be unsafe. 

I would say it is problematic because it is not contained but
ends up in a lot of places, i.e. all child processes. One could
at least encode special characters etc... 

> I think assuming the mere contents of an environment variable
> restricted to a namespace like HTTP_* and kept well away from, say, 
> LD_* would not be interpreted as executable code is pretty reasonable.


Martin



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140925194743.52fbc006@lemur

Re: Bug#762839: bash without importing shell functions from the environment

[Russ Allbery]

Martin Uecker  writes:

> While everybody is looking at bash, isn't this the real the injection
> part? Why are there still programs which copy stuff from the network
> into environment without proper sanitation?

The previous sanitization for environment variables mostly focused on not
letting the client set arbitrary environment variables and instead tightly
restricting which variables could be set.  The problem with this
vulnerability is that the varible doesn't matter, only the value, which is
a new type of problem.

Also, prior to the discovery of this bug, I'm dubious that anyone would
have found this particular environment variable pattern all that
concerning.  It's not obvious why it would be an issue.  So only a pure
whitelisting approach on environment variable *contents* would have been
effective, and it's hard to define what language you want to restrict the
contents to.

It's very useful in some web situations to get access to arbitrary client
data via environment variables.  I sometimes want *exactly* what the
client sent as its Browser string, for instance, metacharacters and all.
I should be able to get that as an environment variable and process it;
there's no obvious reason to believe that should be unsafe.  I think
assuming the mere contents of an environment variable restricted to a
namespace like HTTP_* and kept well away from, say, LD_* would not be
interpreted as executable code is pretty reasonable.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8761gbp1tf@hope.eyrie.org

Re: Bug#762839: bash without importing shell functions from the environment

[Russ Allbery]

Brian May  writes:

> I thought sudo was suppose to be ok, sure doesn't look ok to me.

> brian@aquitard:~$ sudo echo='() { /bin/echo bar; }'  bash
> root@aquitard:/home/brian# echo hello
> bar

I think you have that backwards, don't you?  Shouldn't that be:

echo='() { /bin/echo bar; }' sudo bash

if you're testing whether sudo sanitizes the environment?

I believe the syntax that you're using runs the command:

echo='() { /bin/echo bar; }'  bash

under sudo.  If you have all-command sudo privileges, you can indeed run
whatever you want via sudo, including commands that set various
interesting environment variables.  :)

sudo should stop you from doing things like this unless you've explicitly
told sudo to allow the client to set any environment variable.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87a95np1zi@hope.eyrie.org

Re: Bug#762839: bash without importing shell functions from the environment

[Brian May]

On 26 September 2014 10:26, Nikolaus Rath  wrote:

> Wasn't there some web server that used to put query script variables
> into the environment of the CGI script? Or am I confusing that with
> PHP's evil register_globals?
>

CGI is just one avenue for attack.

There are other avenues. e.g. the ssh one, if I understand correctly, would
allow setting any environment variable to any value.

See list of packages here:

https://access.redhat.com/articles/1200223

In addition, if there are any setuid/setgid program, either in Debian or
installed locally, that make external calls to bash, these would be
vulnerable.

I thought sudo was suppose to be ok, sure doesn't look ok to me.

brian@aquitard:~$ sudo echo='() { /bin/echo bar; }'  bash
root@aquitard:/home/brian# echo hello
bar

brian@aquitard:~$ sudo echo='() { /bin/echo bar; }'  ./test.sh
bar

brian@aquitard:~$ sudo echo='() { /bin/echo bar; id; }'  ./test.sh
bar
uid=0(root) gid=0(root) groups=0(root)
-- 
Brian May 

Re: Bug#762839: bash without importing shell functions from the environment

[Martin Uecker]

Samuel Thibault:
> Matthias Urlichs, le Thu 25 Sep 2014 21:17:58 +0200, a écrit :
> > Samuel Thibault:
> > > Sounds crazy to me.
> > > 
> > Definitely. This is now out in the wild; exploits which simply replace
> > echo or cat-without-/bin are going to happen. :-/
> 
> That's not so easy to exploit. You have to manage to inject those precise
> variable names.

While everybody is looking at bash, isn't this the real the
injection part? Why are there still programs which copy stuff
from the network into environment without proper sanitation? 
This bash bug makes this easy to exploit, but it is not hard
to imagine that this can confuse other programs in different
ways. In fact, there were very similar bugs in the past:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0997



Martin


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140925182221.4ff545d1@lemur

Re: Bug#762839: bash without importing shell functions from the environment

[Nikolaus Rath]

Samuel Thibault  writes:
> Matthias Urlichs, le Thu 25 Sep 2014 21:17:58 +0200, a écrit :
>> Samuel Thibault:
>> > Sounds crazy to me.
>> > 
>> Definitely. This is now out in the wild; exploits which simply replace
>> echo or cat-without-/bin are going to happen. :-/
>
> That's not so easy to exploit. You have to manage to inject those precise
> variable names.

Wasn't there some web server that used to put query script variables
into the environment of the CGI script? Or am I confusing that with
PHP's evil register_globals?

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87oau3mdkv@vostro.rath.org

Re: Bug#762839: bash without importing shell functions from the environment

[Samuel Thibault]

Matthias Urlichs, le Thu 25 Sep 2014 21:17:58 +0200, a écrit :
> Samuel Thibault:
> > Sounds crazy to me.
> > 
> Definitely. This is now out in the wild; exploits which simply replace
> echo or cat-without-/bin are going to happen. :-/

That's not so easy to exploit. You have to manage to inject those precise
variable names.

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140925203900.gt3...@type.youpi.perso.aquilenet.fr

Re: Bug#762839: bash without importing shell functions from the environment

[Matthias Urlichs]

Hi,

Samuel Thibault:
> Sounds crazy to me.
> 
Definitely. This is now out in the wild; exploits which simply replace
echo or cat-without-/bin are going to happen. :-/

Maybe we should add the patched version, with an appropriate NEWS entry,
to backports?

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: Bug#762839: bash without importing shell functions from the environment

[Samuel Thibault]

Ian Jackson, le Thu 25 Sep 2014 16:29:05 +0100, a écrit :
> I have prepared bash packages which do not honour any shell functions
> they find in the environment.  IMO that is a crazy feature, which
> ought to be disabled.  (I'm running this on chiark now and nothing has
> visibly broken yet.)

Yes.

€ cat test.sh
#!/bin/bash
echo foo

€ export echo='() { /bin/echo bar; }'

€ ./test.sh 
bar

Sounds crazy to me.

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140925162026.ga11...@type.bordeaux.inria.fr