Nikolaus Rath writes (Re: bash without importing shell functions from the
environment):
I think the latter. I was actually curious as well and checked. The
wheezy version has custom debian/patches handling where e.g.
debian/patches/series is processed by the C preprocessor. I think
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
--
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
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
Am 25.09.2014 um 17:29 schrieb Ian Jackson:
(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
On Tue, Sep 30, 2014 at 07:58:38PM +0200, Matthias Klose wrote:
so maybe as a non-native speaker I am unaware of some joke here, or are you
just
trolling about something fixed for jessie/unstable?
I was curious to see what Ian was complaining about, and what has changed up to
the jessie
Matthias Klose d...@debian.org writes:
Am 25.09.2014 um 17:29 schrieb Ian Jackson:
(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
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
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
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
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
On Thu, 25 Sep 2014, shawn wilson wrote:
In that case, I'd think busybox's sh is *much* more minimalist. Why dash
over busybox?
There is something called bugs. The busybox implementation
is artificially limited. Also, it uses the busybox common
code, which makes its codebase rather large.
The
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,
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,
Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote:
Just to make things clear -- you're advocating #!/bin/sh and running
dash
as /bin/sh?
(Likely alternatives include at least ksh and mksh, formerly pdksh.)
I think this has already happened wherever it was
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
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
On Thu, Sep 25, 2014 at 04:29:05PM +0100, Ian Jackson wrote:
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.)
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
Jonathan Dowland wrote:
Thank you very much for doing this. I would love to see Debian transition to
having this facility disabled by default at some point in the future.
Florian Weimer's patch doesn't go that far, instead environment
variables have to have special BASH_FUNC_FOO() names before
Joey Hess writes (Re: bash without importing shell functions from the
environment):
Jonathan Dowland wrote:
Thank you very much for doing this. I would love to see Debian
transition to having this facility disabled by default at some
point in the future.
Florian Weimer's patch doesn't
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
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.
€
Hi Ian,
On Thu, September 25, 2014 17:29, Ian Jackson wrote:
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.)
A
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
Le jeudi 25 septembre 2014 à 16:29 +0100, Ian Jackson 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.)
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
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
Since I’m pretty sure we haven’t uncovered all of bash’s “features”,
wouldn’t it be a good opportunity to make a release goal of killing all
scripts with a #!/bin/bash shebang?
Just to make things clear -- you're advocating #!/bin/sh and running dash
as /bin/sh?
(Likely alternatives include
Josselin Mouette j...@debian.org writes:
Since I’m pretty sure we haven’t uncovered all of bash’s “features”,
wouldn’t it be a good opportunity to make a release goal of killing all
scripts with a #!/bin/bash shebang?
That may be overkill, but I will say that I'm feeling *extremely* grateful
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
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
On Thu, Sep 25, 2014 at 12:35 PM, Josselin Mouette j...@debian.org wrote:
Le jeudi 25 septembre 2014 à 16:29 +0100, Ian Jackson 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
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='()
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
On Sep 25, 2014 9:36 PM, Russ Allbery r...@debian.org wrote:
Josselin Mouette j...@debian.org writes:
Since I’m pretty sure we haven’t uncovered all of bash’s “features”,
wouldn’t it be a good opportunity to make a release goal of killing all
scripts with a #!/bin/bash shebang?
That may
shawn wilson ag4ve...@gmail.com writes:
On Sep 25, 2014 9:36 PM, Russ Allbery r...@debian.org wrote:
That may be overkill, but I will say that I'm feeling *extremely*
grateful the last few days that we pushed forward with switching
/bin/sh to dash, even though some folks thought this was a
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
On Thu, Sep 25, 2014 at 06:49:32PM -0700, Cameron Norman wrote:
Perhaps making all those scripts either depend on bash or transition
to /bin/sh would be a good idea. This could be done through a lintian
warning I think. Then people interested in working on fully
transitioning to /bin/sh could
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
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
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
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
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
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
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
46 matches
Mail list logo
