Please create and enforce a system-wide policy to unset GREP_OPTION by default

Thanks for your bug report and sorry for not getting in contact with you earlier.
Does your bug still exists? And does it in development versions?
Will you please check this, if your bug still exists please tell here, otherwise you can set the bug status to invalid to close this bug.
Thanks in advance.

Hmm.....I seem to have duplicated this in Bug #75031

It still is a bug, see the last comment in the other bug. I would suggest unsetting GREP_OPTION in all the /etc/init.d/* scripts, especially if it uses grep.

Ciao!

Thanks for your answer.
Is this a duplicate of bug #75031 or is it just about the same GREP_OPTION and a problem in ubuntu instead of mysql?
Thanks

It needs to be considered as a distro policy level, so I guess they are different. But it's the same issue -- GREP_OPTIONS changes the behavior of a tool that is used for various purposes, including things that can effect security.

I simple tool (attached) can be used to detect shell scripts that need changing....

Ciao!

Have you set the GREP_OPTION for the root user for init scripts? If not where have you set it?
And why might it be a security issue?
Thanks in advance

I do set GREP_OPTIONS in my .bashrc, etc. Specifically, I use GREP_OPTIONS=--color=auto

It is a common command someone might set. Either one off (just to see color for some greps) or routinely (like I have in my bashrc).

It is a security issue because it open up holes, prevent actions from happening, etc. if a grep doesn't return what the user expects.

For example:
---------------------------
$ grep -E -q local /etc/hosts ; echo $?
0

$ env GREP_OPTIONS=-P grep -E -q local /etc/hosts ; echo $?
grep: conflicting matchers specified
2

$ env GREP_OPTIONS=-f/dev/zero grep -E -q local /etc/hosts ; echo $?
grep: memory exhausted
1
----------------------------

Just for a few examples of how this can go wrong, maliciously or otherwise.

GREP_OPTIONS can be used to read in files (-f) or change the meaning of a grep (illegal options) or otherwise corrupt it's usage in a script.

The fact that a tool that is usually used without considering how it could fail is used everyplace is the problem. I suggest just add something to /lib/lsb/init-functions to unset GREP_OPTIONS.

I don't have a specific security hole in mind, but something like a firewall going down might try to turn off packet forwarding, but think it's already down and leave it up. Or something like that.

Ciao!

Thanks for your answer!
This is not a security bug, because the security bugs are about data loss or privacy.
However it's still a bug in Ubuntu.
I'll set the package to grep and than you have to wait till someone from the grep team confirms it.
Thanks for your cooperation !

P.s for the record you can put your grep version here.

grep (GNU grep) 2.5.1

i think this bug should not be reported against grep but against ubuntu, if that is possible. i tried to do that but i failed.

just for reference, here is a list of bug reports about problems caused by GREP_OPTIONS:
bug #75031
bug #257984
bug #398393
bug #540733

also related:
bug #545675

and for the fun of it, i also started a brainstorm about this:
http://brainstorm.ubuntu.com/idea/24141/

GREP_OPTIONS is useful, because it allows the user set one option for many forms of grep (grep, egrep, fgrep, rgrep, zgrep, bzgrep, bzfgrep, bzegrep, etc.).

For example, here's what the man page for bzgrep says:

    If the GREP environment variable is set, bzgrep uses it as the grep program to be invoked.

    For example:

           for sh: GREP=fgrep bzgrep string files
           for csh: (setenv GREP fgrep; bzgrep string files)

If you disable GREP_OPTIONS and insist that users replace it with an alias, then users will need to set an alias for every form of *grep, and there are many different greps.

I'm not asking to remove GREP_OPTIONS from grep. I'm saying that in system scripts, such as the stuff in /etc/init.d/*, should some how ignore GREP_OPTIONS. I broke scripts by setting GREP_OPTIONS in non-obvious ways.

It's really hard to track down these problems, so maybe we should unset them automatically in /etc/init.d/* scripts and other system scripts.

I do not understand why this is marked as duplicate of bug #75031.

bug #75031 is about the mysql init.d script choking on a poorly set GREP_OPTION.

bug #67141 (this bug) is about a system-wide policy to unset GREP_OPTION by default.

if ubuntu has no interest in setting up a system-wide policy then mark this bug as WONTFIX. marking this as duplicate makes no sense.

In attempting to triage this bug, I'm unable to find GREP_OPTIONS in env command output or in my .bashrc. Is this still an issue in the latest release, if so can you specify where this variable can be found after a default installation.

komputes: They aren't in the init scripts, etc.

The problem is that if a user adds GREP_OPTIONS to their environment (manually, or via .bashrc, etc.) then it can break init.d scripts, etc.

At the time, if you did `env GREP_OPTIONS=-E /etc/init.d/blah start` it could break the `blah` script in unpredictable ways. Also it can break various scripts in /usr/bin and /bin

Depending on the users setup, GREP_OPTIONS may also make it through a sudo call.

The reason why this is a problem is that troubleshooting this kind of problem can be very difficult because only the person with GREP_OPTIONS set will have the breakage and it'll not be obvious that this is happening.

I hope that clears this up.

Ciao!

[Expired for Ubuntu because there has been no activity for 60 days.]