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 preproc
Matthias Klose 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
>> take th
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 ver
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
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
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
>
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
--
Som
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 environ
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 UNSUBSCR
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 th
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
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 b
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.)
T
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 a
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.
>
> b
Juliusz Chroboczek 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 easy. So to
remove /bin/bash sc
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,
>
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
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.
Th
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
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
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 lenien
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 allow
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
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 t
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 a
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 treat
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 n
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 cou
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 most
shawn wilson writes:
> On Sep 25, 2014 9:36 PM, "Russ Allbery" 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 bad idea.
>> Having the she
On Sep 25, 2014 9:36 PM, "Russ Allbery" wrote:
>
> Josselin Mouette 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
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
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 b
On Thu, Sep 25, 2014 at 12:35 PM, Josselin Mouette 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 disabled. (I'm r
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
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 exploi
Josselin Mouette 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
the last few
> 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
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 explo
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 th
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.)
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
De
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.)
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.
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
46 matches
Mail list logo
