Quoting "Ruben Rodriguez" :
This has been fixed in bash 4.4.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Reported through rt.gnu.org:
I'd like to report a security bug in rbash. the BASH_CMDS env
variable is writable from within rbash. so something like this
BASH_CMDS[poop]=/bin/bash;poop
Quoting "Ola Lundqvist" :
This is known.
I "complained" at the time, as it can be seen here:
https://lists.gnu.org/archive/html/bug-bash/2015-12/msg00112.html
Version: all (see note below)
Hardware: all
Operating system: Debian GNU Linux (but all should be affected)
Compiler: gcc
Hi
In CVE-
Quoting "Chet Ramey" :
Which should not be affected by what we're talking about, which is not
importing PS4 from the environment when uid == 0.
He later said "(Blocking PS4 and not SHELLOPTS=xtrace would work for
me in that
regard)".
Still shows how useful xtrace is and how it is necessa
Quoting "Stephane Chazelas" :
I don't know if you can make a non-interactive bash write to the
$HISTFILE, but bash, even when non-interactive, even when called
as sh, with SHELLOPTS=history will *read* the HISTFILE.
Thanks for clearing that up for me. Makes sense.
Quoting "Chet Ramey" :
I
Quoting "Chet Ramey" :
On 12/15/15 11:37 AM, up201407...@alunos.dcc.fc.up.pt wrote:
You just need to enable history (set -o history). History is independent
of whether or not the shell is interactive; it's just enabled by default
in interactive shells.
doing a "set -o history" didn't work f
Quoting "Stephane Chazelas" :
I understand what you're saying.
As much as we would like, there's no way of stopping all attack
vectors by only hardening bash, not only that, but also taking away
its useful features.
Though I still believe PS4 shouldn't be imported from the environment.
Sho
Quoting "Stephane Chazelas" :
SHELLOPTS+PS4 is a known way to have the shell run arbitrary
commands. Before shellshock, env /bin/date='() { cmd; }' was
another one. The fix for shellshock closed that one.
Yes, exporting a function was a better known attack against this.
I can see why one mi
Quoting "Chet Ramey" :
On 12/10/15 2:16 PM, up201407...@alunos.dcc.fc.up.pt wrote:
Hello,
This is a suggestion for a bash security hardening patch which prevents
xtrace from being initialized to the SHELLOPTS environment variable when a
new shell starts.
This is far too drastic a solution to
Quoting Stephane Chazelas:
setuid bash will ignore SHELLOPTS (and drop privileges except
for the patched Debian version). In your case, since you're
doing a setuid(0), bash is no longer called as setuid, so can't
detect it.
Correct.
So you've got a shell started as root with the environment
Regarding my last email, instead of a "break;" it should be a "continue;".
Just realized that xtrace might not always be last in $SHELLOPTS, so
it would break out of the while loop and stop the parsing of the rest
of the options.
$ cat file.c
int main()
{
system("env");
}
$ gcc file.
Hello,
This is a suggestion for a bash security hardening patch which
prevents xtrace from being initialized to the SHELLOPTS environment
variable when a new shell starts.
xtrace can be used to exploit bogus system()/popen() calls on setuid
binaries via a specially crafted PS4 environment
11 matches
Mail list logo
