Re: Bug#762839: bash without importing shell functions from the environment
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
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
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: Re: Bug#762839: bash without importing shell functions from the environment
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
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: Bug#762839: bash without importing shell functions from the environment
Nikolaus Rath, le Thu 25 Sep 2014 17:26:40 -0700, a écrit : Samuel Thibault sthiba...@debian.org 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
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
Brian May br...@microcomaustralia.com.au wrote:
On 26 September 2014 14:15, Russ Allbery r...@debian.org 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
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 vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/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
On 2014-09-26 10:33:20 +0200, Josselin Mouette wrote:
Brian May br...@microcomaustralia.com.au 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 vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/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
On Sep 25, 2014 3:18 PM, Matthias Urlichs matth...@urlichs.de 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
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
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
Re: Bug#762839: bash without importing shell functions from the environment
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
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
Samuel Thibault sthiba...@debian.org 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. 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
On 26 September 2014 10:26, Nikolaus Rath 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.
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 br...@microcomaustralia.com.au
Re: Bug#762839: bash without importing shell functions from the environment
Brian May br...@microcomaustralia.com.au 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) http://www.eyrie.org/~eagle/
--
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
Martin Uecker uec...@eecs.berkeley.edu 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) http://www.eyrie.org/~eagle/ -- 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: Re: Bug#762839: bash without importing shell functions from the environment
Russ Allbery r...@debian.org: Martin Uecker uec...@eecs.berkeley.edu 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
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: Bug#762839: bash without importing shell functions from the environment
On 26 September 2014 12:08, Russ Allbery r...@debian.org 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 br...@microcomaustralia.com.au
Re: Bug#762839: bash without importing shell functions from the environment
Brian May br...@microcomaustralia.com.au writes:
On 26 September 2014 12:08, Russ Allbery r...@debian.org 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) http://www.eyrie.org/~eagle/
--
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
On 26 September 2014 14:15, Russ Allbery r...@debian.org 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 br...@microcomaustralia.com.au
Re: Bug#762839: bash without importing shell functions from the environment
On Fri, Sep 26, 2014 at 01:37:48PM +1000, Brian May wrote:
On 26 September 2014 12:08, Russ Allbery r...@debian.org 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 br...@microcomaustralia.com.au 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) http://www.eyrie.org/~eagle/
--
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
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
