SHELLOPTS=xtrace security hardening

2015-12-10 Thread up201407890 

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 variable leading to  
privilege escalation, like so:



# gcc -xc - -otest <<< 'int main() { setuid(0); system("/bin/date"); }'
# chmod 4755 ./test
# ls -l ./test
-rwsr-xr-x. 1 root root 8549 Dec 10 18:06 ./test
# exit
$ env -i SHELLOPTS=xtrace PS4='$(id)' ./test
uid=0(root)
Thu Dec 10 18:06:36 WET 2015


This means, that setuid programs which call system(3)/popen(3) (a  
horrendously bad practice in any case) are vulnerable, since it's safe  
to assume that most of these do not ignore such environment variables.


CVE-2005-2959 reported by Tavis Ormandy would be an example against sudo


from bash-4.2.53/shell.c:



  1722/* Initialize the shell options.  Don't import the shell options
  1723   from the environment variables $SHELLOPTS or $BASHOPTS if we are
  1724   running in privileged or restricted mode or if the shell  
is running

  1725   setuid. */
  1726  #if defined (RESTRICTED_SHELL)
  1727initialize_shell_options  
(privileged_mode||restricted||running_setuid);

  1728initialize_bashopts (privileged_mode||restricted||running_setuid);
  1729  #else
  1730initialize_shell_options (privileged_mode||running_setuid);
  1731initialize_bashopts (privileged_mode||running_setuid);
  1732  #endif



initialize_shell_options() is defined in bash-4.2.53/builtins/set.def



   555  void
   556  initialize_shell_options (no_shellopts)
   557   int no_shellopts;
   558  {
   559char *temp;
   560SHELL_VAR *var;
   561
   562if (no_shellopts == 0)
   563  {
   564var = find_variable ("SHELLOPTS");
   565/* set up any shell options we may have inherited. */
   566if (var && imported_p (var))
   567  {
   568		  temp = (array_p (var) || assoc_p (var)) ? (char *)NULL :  
savestring (value_cell (var));

   569if (temp)
   570  {
   571parse_shellopts (temp);
   572free (temp);
   573  }
   574  }
   575  }
   576
   577/* Set up the $SHELLOPTS variable. */
   578set_shellopts ();
   579  }



parse_shellopts() is also defined in bash-4.2.53/builtins/set.def



   535  void
   536  parse_shellopts (value)
   537   char *value;
   538  {
   539char *vname;
   540int vptr;
   541
   542vptr = 0;
   543while (vname = extract_colon_unit (value, &vptr))
   544  {
   545set_minus_o_option (FLAG_ON, vname);
   546free (vname);
   547  }
   548  }




Suggested patch:


$ diff -Naur bash-4.2.53.patch/bash-4.2.53 bash-4.2.53
diff -Naur bash-4.2.53.patch/bash-4.2.53/builtins/set.def  
bash-4.2.53/builtins/set.def
--- bash-4.2.53.patch/bash-4.2.53/builtins/set.def  2011-01-10  
14:22:25.0 +

+++ bash-4.2.53/builtins/set.def2015-12-10 18:29:54.494932199 +
@@ -542,6 +542,10 @@
   vptr = 0;
   while (vname = extract_colon_unit (value, &vptr))
 {
+  /* xtrace can be used to exploit bogus system()/popen() calls  
on setuid binaries
+ via a specially crafted PS4 environment variable leading to  
privilege escalation. */

+  if(!strcmp(vname, "xtrace"))
+break;
   set_minus_o_option (FLAG_ON, vname);
   free (vname);
 }




After compilation:


# rm /bin/bash
# cp bash-4.2.53/bash /bin/bash
# ls -l /bin/sh
lrwxrwxrwx. 1 root root 9 Oct  4 18:18 /bin/sh -> /bin/bash
# exit
$ env -i SHELLOPTS=xtrace PS4='$(id)' ./test
Thu Dec 10 18:30:41 WET 2015


Thanks,
Federico Bento.


This message was sent using IMP, the Internet Messaging Program.

Re: SHELLOPTS=xtrace security hardening

2015-12-11 Thread up201407890 

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.c
$ env -i SHELLOPTS=xtrace:history ./a.out
SHELLOPTS=braceexpand:hashall:interactive-comments:posix
PWD=/home/saken
SHLVL=1
_=/bin/env

history should have been here, so it should be:

$ diff -Naur bash-4.2.53.patch/bash-4.2.53 bash-4.2.53
diff -Naur bash-4.2.53.patch/bash-4.2.53/builtins/set.def  
bash-4.2.53/builtins/set.def
--- bash-4.2.53.patch/bash-4.2.53/builtins/set.def  2011-01-10  
14:22:25.0 +

+++ bash-4.2.53/builtins/set.def2015-12-10 18:29:54.494932199 +
@@ -542,6 +542,10 @@
   vptr = 0;
   while (vname = extract_colon_unit (value, &vptr))
 {
+  /* xtrace can be used to exploit bogus system()/popen() calls  
on setuid binaries
+ via a specially crafted PS4 environment variable leading to  
privilege escalation. */

+  if(!strcmp(vname, "xtrace"))
+continue;
   set_minus_o_option (FLAG_ON, vname);
   free (vname);
 }


After bash compilation:

$ env -i SHELLOPTS=xtrace:history ./a.out
SHELLOPTS=braceexpand:hashall:history:interactive-comments:posix
PWD=/home/saken
SHLVL=1
_=/bin/env

history is now available as an option.


Thanks,
Federico Bento


Quoting up201407...@alunos.dcc.fc.up.pt:


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 variable leading to  
privilege escalation, like so:



# gcc -xc - -otest <<< 'int main() { setuid(0); system("/bin/date"); }'
# chmod 4755 ./test
# ls -l ./test
-rwsr-xr-x. 1 root root 8549 Dec 10 18:06 ./test
# exit
$ env -i SHELLOPTS=xtrace PS4='$(id)' ./test
uid=0(root)
Thu Dec 10 18:06:36 WET 2015


This means, that setuid programs which call system(3)/popen(3) (a  
horrendously bad practice in any case) are vulnerable, since it's  
safe to assume that most of these do not ignore such environment  
variables.


CVE-2005-2959 reported by Tavis Ormandy would be an example against sudo


from bash-4.2.53/shell.c:



  1722/* Initialize the shell options.  Don't import the shell options
  1723   from the environment variables $SHELLOPTS or $BASHOPTS if we are
  1724   running in privileged or restricted mode or if the  
shell is running

  1725   setuid. */
  1726  #if defined (RESTRICTED_SHELL)
  1727initialize_shell_options  
(privileged_mode||restricted||running_setuid);

  1728initialize_bashopts (privileged_mode||restricted||running_setuid);
  1729  #else
  1730initialize_shell_options (privileged_mode||running_setuid);
  1731initialize_bashopts (privileged_mode||running_setuid);
  1732  #endif



initialize_shell_options() is defined in bash-4.2.53/builtins/set.def



   555  void
   556  initialize_shell_options (no_shellopts)
   557   int no_shellopts;
   558  {
   559char *temp;
   560SHELL_VAR *var;
   561
   562if (no_shellopts == 0)
   563  {
   564var = find_variable ("SHELLOPTS");
   565/* set up any shell options we may have inherited. */
   566if (var && imported_p (var))
   567  {
   568		  temp = (array_p (var) || assoc_p (var)) ? (char *)NULL :  
savestring (value_cell (var));

   569if (temp)
   570  {
   571parse_shellopts (temp);
   572free (temp);
   573  }
   574  }
   575  }
   576
   577/* Set up the $SHELLOPTS variable. */
   578set_shellopts ();
   579  }



parse_shellopts() is also defined in bash-4.2.53/builtins/set.def



   535  void
   536  parse_shellopts (value)
   537   char *value;
   538  {
   539char *vname;
   540int vptr;
   541
   542vptr = 0;
   543while (vname = extract_colon_unit (value, &vptr))
   544  {
   545set_minus_o_option (FLAG_ON, vname);
   546free (vname);
   547  }
   548  }




Suggested patch:


$ diff -Naur bash-4.2.53.patch/bash-4.2.53 bash-4.2.53
diff -Naur bash-4.2.53.patch/bash-4.2.53/builtins/set.def  
bash-4.2.53/builtins/set.def
--- bash-4.2.53.patch/bash-4.2.53/builtins/set.def  2011-01-10  
14:22:25.0 +

+++ bash-4.2.53/builtins/set.def2015-12-10 18:29:54.494932199 +
@@ -542,6 +542,10 @@
   vptr = 0;
   while (vname = extract_colon_unit (value, &vptr))
 {
+  /* xtrace can be used to exploit bogus system()/popen() calls  
on setuid binaries
+ via a specially crafted PS4 environment variable leading  
to privilege escalation. */

+  if(!strcmp(vname, "xtrace"))
+break;
   set_minus_o_option (FLAG_ON, vname);

Re: SHELLOPTS=xtrace security hardening

2015-12-11 Thread up201407890 

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 of
the caller (except for the env vars stripped by the libc),
SHELLOPTS+PS4 will be an issue, but also TZ (if it's a file
path, the file will end up being read as root), IFS (not for bash,
but for dash or posh), PATH, CDPATH, exported functions and all the
other variables that sudo for instance blacklists.

Doing setuid(0); system(something) is just suicide unless you've
cleared the whole environment and set only a few necessary env
vars like sudo does.


I agree. Sadly, some people aren't aware of that.
There have been some trivial vulnerabities like CVE-2013-4011 and  
CVE-2013-1662 that are some-what recent.



On the other hand,

One of the few things I occasionaly use bash for is for
SHELLOPTS=xtrace. It is very handy for debugging commands that
invoke shell scripts. I even end up sometimes replacing /bin/sh
with bash just for that.

So yes, it would be hardening, but hardening for already broken
applications and at the expense of a useful feature IMO.


Yes, I understand it may be useful in some cases.

It is because of these broken applications that privileged mode even  
exists in bash in the first place (not Debian's bash). This could  
potentially eliminate almost all system()/popen() vulnerabilities once  
and for all, unless there is a classic ";somecommand", but in that  
case they're just asking for it.


Since doing a setuid(0) bash will no longer be called as setuid, I  
don't think there is another way of stopping this, unless a kernel  
change is made, AFAIK. But that would never happen.




That's also why I find bash dropping privileges when setuid in
non-Debian systems a double-edged sword. That means people end
up doing something a lot worse to work around it.


But if it wasn't for that, most, if not all, setuid binaries that call  
system()/popen() would be vulnerable.



At least on Debian and all other systems that don't use bash or
mksh as their sh, if they do system("/some/cmd"), the shell and
cmd run as root but at least they can now that they are setuid
so they can enter a restricted mode.


They can, but they never get it right.

Cheers,
Federico Bento.


This message was sent using IMP, the Internet Messaging Program.

Re: SHELLOPTS=xtrace security hardening

2015-12-13 Thread up201407890 

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 the problem you have posed.


xtrace can be used to exploit bogus system()/popen() calls on setuid
binaries via a specially crafted PS4 environment variable leading to
privilege escalation, like so:


I don't really see privilege escalation here.  Your setuid root program
sets the real and effective UIDs to 0 and calls system().  There is no
way to distinguish this as the result of running a setuid program, and
any privilege escalation takes place before system() runs.


Yes, privilege escalation happens before system(), but it is possible  
to run arbitrary commands as uid 0.



I have to tell you, if I wanted to exploit a program written this poorly,
I wouldn't mess around with SHELLOPTS.  I'd go straight to PATH.


The test case I presented couldn't be abused by PATH because i gave it  
a full path, as in system("/bin/date")


Here's another example:

# cat test.c
int main()
{
putenv("PATH=/bin:/usr/bin");
setuid(0);
system("/bin/date");
}
# gcc test.c
# chmod 4755 a.out
# exit
$ env -i SHELLOPTS=xtrace PS4='$(id)' ./a.out
uid=0(root)
Sun Dec 13 19:35:14 WET 2015

As horrible as it is to setuid() and system(), this wouldn't seem like  
a vulnerable program.


AFAIK, privmode has made it into bash to defend against these poorly  
written programs, as seen in section 7 of the bash NOTES file.

http://tiswww.case.edu/php/chet/bash/NOTES

So, in upstream bash, if uid != euid it drops privileges.
This means that if someone really wants to change privileges in a  
setuid binary, he just needs to take an extra step and add  
setuid()/setreuid() in there. After that, they'd be equally as  
vulnerable. Obviously bash does more than it's asked by using such  
functionality, which some other shells don't.

Only recently dash started adopting it.
https://bugs.launchpad.net/ubuntu/+source/dash/+bug/1215660/comments/6


This isn't a good reason to take xtrace out of $SHELLOPTS unconditionally.
It's not even a good enough reason to ignore SHELLOPTS if the shell is
running as uid 0.


This doesn't completely remove it.

For example, bash -x would still work:

$ cat test.sh
#!/bin/bash

printf 'Hello Chet\n'
echo $SHELLOPTS
$ bash -x test.sh
+ printf 'Hello Chet\n'
Hello Chet
+ echo braceexpand:hashall:interactive-comments:xtrace
braceexpand:hashall:interactive-comments:xtrace


Only problem would be, as Stephane said, when other programs invoke  
shell scripts.


Maybe another way of solving this problem would be initializing $PS4  
with it's default value "+ ", and not importing it from the environment.

I believe that would be a much better solution.



$ diff -Naur bash-4.2.53 bash-4.2.53.patch/
diff -Naur bash-4.2.53/variables.c bash-4.2.53.patch/variables.c
--- bash-4.2.53/variables.c 2014-10-01 20:54:55.0 +0100
+++ bash-4.2.53.patch/variables.c   2015-12-13 21:51:38.926476398 +
@@ -465,7 +465,10 @@
 #endif
   set_if_not ("PS2", secondary_prompt);
 }
-  set_if_not ("PS4", "+ ");
+  /* Don't allow PS4 to be imported from the environment.
+ Specially crafted SHELLOPTS+PS4 could be used to exploit
+ bogus system(3)/popen(3) calls in setuid executables. */
+  bind_variable ("PS4", "+ ", 0);

   /* Don't allow IFS to be imported from the environment. */
   temp_var = bind_variable ("IFS", " \t\n", 0);



# rm /bin/bash
# cp ./bash /bin/bash
# exit
$ env -i SHELLOPTS=xtrace PS4='$(id)' ./a.out
+ /bin/date
Sun Dec 13 21:56:38 WET 2015


Thoughts on this?


Thanks,
Federico Bento.


--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/






This message was sent using IMP, the Internet Messaging Program.

Re: SHELLOPTS=xtrace security hardening

2015-12-14 Thread up201407890 

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 might want to close a path to easy privilege
escalation, but IMO, the fault here is not with bash but with
setuid applications invoking other applications, let alone a
shell without sanitizing the environment.


Obviously it's always the applications fault.
The thing is that a simple patch in bash can stop most of these  
applicaions from getting exploited.

It would be easier hardening bash than securing those applications one by one.

Also, if you haven't read my previous email, my new suggestion of  
initialiing $PS4 with it's default value "+ ", and not importing it  
from the environment would be a much better solution.

This way xtrace can still be used, and the prompt would be it's default "+ ".


$ diff -Naur bash-4.2.53 bash-4.2.53.patch/
diff -Naur bash-4.2.53/variables.c bash-4.2.53.patch/variables.c
--- bash-4.2.53/variables.c 2014-10-01 20:54:55.0 +0100
+++ bash-4.2.53.patch/variables.c   2015-12-13 21:51:38.926476398 +
@@ -465,7 +465,10 @@
 #endif
   set_if_not ("PS2", secondary_prompt);
 }
-  set_if_not ("PS4", "+ ");
+  /* Don't allow PS4 to be imported from the environment.
+ Specially crafted SHELLOPTS+PS4 could be used to exploit
+ bogus system(3)/popen(3) calls in setuid executables. */
+  bind_variable ("PS4", "+ ", 0);

   /* Don't allow IFS to be imported from the environment. */
   temp_var = bind_variable ("IFS", " \t\n", 0);



# rm /bin/bash
# cp ./bash /bin/bash
# exit
$ env -i SHELLOPTS=xtrace PS4='$(id)' ./a.out
+ /bin/date
Sun Dec 13 21:56:38 WET 2015


Thoughts?


This message was sent using IMP, the Internet Messaging Program.

Re: SHELLOPTS=xtrace security hardening

2015-12-14 Thread up201407890 

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.


Should we also block SHELLOPTS=history
HISTFILE=/some/file like /proc/$pid/fd/$fd and
TZ=/proc/$pid/fd/$fd (like for your /bin/date command) as that
allows DoS on other processes (like where those fds are for
pipes).


Mind explaining this one?
I can't seem to write to HISTFILE in a non-interactive shell, or am i  
missing something?


Thanks.



This message was sent using IMP, the Internet Messaging Program.

Re: SHELLOPTS=xtrace security hardening

2015-12-15 Thread up201407890 

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 for me, only when i added a "history
-a" eg:


$ cat x19
#!/bin/bash

rm -f /tmp/history  # make sure it's not there

set -o history
HISTFILE="/tmp/history"
HISTSIZE="1000"

printf 'something\n'
$ ../bash-4.3-patched/bash ./x19
something
$ ls -l /tmp/history
-rw---  1 chet  wheel  61 Dec 15 11:48 /tmp/history
$ cat /tmp/history
HISTFILE="/tmp/history"
HISTSIZE="1000"
printf 'something\n'



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 for me, only when i added a "history
-a" eg:


$ cat x19
#!/bin/bash

rm -f /tmp/history  # make sure it's not there

set -o history
HISTFILE="/tmp/history"
HISTSIZE="1000"

printf 'something\n'
$ ../bash-4.3-patched/bash ./x19
something
$ ls -l /tmp/history
-rw---  1 chet  wheel  61 Dec 15 11:48 /tmp/history
$ cat /tmp/history
HISTFILE="/tmp/history"
HISTSIZE="1000"
printf 'something\n'



$ cat x19
#!/bin/bash

rm -f /tmp/history# make sure it's not there

set -o history
HISTFILE="/tmp/history"
HISTSIZE="1000"

printf 'something\n'
$ bash ./x19
something
$ ls -l /tmp/history
ls: cannot access /tmp/history: No such file or directory
$ bash --version
GNU bash, version 4.2.53(1)-release (x86_64-redhat-linux-gnu)

Or did you just patch it, since you used "../bash-4.3-patched/bash ./x19" ?


This message was sent using IMP, the Internet Messaging Program.

Re: SHELLOPTS=xtrace security hardening

2015-12-15 Thread up201407890 

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 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.


Maybe if running with uid 0.


That's something to think about.


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 for me, only when i added a  
"history -a" eg:


$ cat test.sh
#!/bin/bash

set -o history
HISTFILE="/tmp/history"
HISTSIZE="1000"

printf 'something\n'
$ ./test.sh
something
$ ls /tmp/history
ls: cannot access /tmp/history: No such file or directory
$ echo history -a >> test.sh
$ ./test.sh
something
$ ls /tmp/history
/tmp/history
$ cat !$
HISTFILE="/tmp/history"
HISTSIZE="1000"
printf 'something\n'
history -a


This message was sent using IMP, the Internet Messaging Program.

Re: SHELLOPTS=xtrace security hardening

2015-12-16 Thread up201407890 

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 necessary.

In this case, yes, blocking PS4 would be best when uid == 0.

It could still be abused when something does setuid() to a uid other  
than 0 though, but obviously not as bad.



This message was sent using IMP, the Internet Messaging Program.

Re: Correction of CVE-2016-7543 is incomplete

2016-10-24 Thread up201407890 

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-2016-7543 a problem was reported that it is possible to privilege
escalate to root.
The correction as seen here
http://lists.gnu.org/archive/html/bug-bash/2016-10/msg9.html
is not complete. Well it do prevent privilege escalation to root, but it is
possible to escalate to any other user and that may be bad too.

The problem has also been reported (by me) in Debian as you can see here:
http://bugs.debian.org/841856

I have attached a tar file with exploit code. The exploit code is used like
this:
make
sudo make root
make test

Test 1 is the exploit for CVE-2016-7543
Test 2 is the exploit for this problem
Test 3 is just a reference test.

The proposed patch essentially disable the whole PS4 variable support for
all users (not only root as the patch was for CVE-2016-7543. Please let me
know if you have a better idea on how to handle this.

Version note: The attached correction is made on a 4.2 system with a patch
for CVE-2016-7543.
However it should apply on 4.4 as well.

Let me know if you need any further details.

Best regards

// Ola

--
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---






This message was sent using IMP, the Internet Messaging Program.

Re: rbash escape security vulnerability

2017-03-10 Thread up201407890 

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 will escape the restricted rbash
shell.


Regards,
- --
Ruben Rodriguez | Senior Systems Administrator, Free Software Foundation
GPG Key: 05EF 1D2F FE61 747D 1FC8  27C3 7FAC 7D26 472F 4409
https://fsf.org | https://gnu.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJYwaXvAAoJEH+sfSZHL0QJTKUQAISM7t/hTfp4HOApE2xFF+At
/cWCYSEZq3ZhNnh8BlSLrNx0AjYYN98nJ3c1xJKMcI87veZ0kT4QRxZEoXF7TLgM
ck/zkXF97uZKwTolj9Opa2OXJTIj8hlWHYTrlkZZjLAywlYMuMHtWf85gs6KJ15x
RguGJylbWYvIreg4ikzCDpaGdjM+K8xnnO/OvD9dxAzC3G2YSlVOy6JuOoWH3KWV
Bw8tHYR+X98koOgu1kugiUk4ngqjOcnO8G02JjXbEsA831mdUbetEMf63mekrSCP
AZDwvt8jA1TTzkY1LT0MpdbVScFeuFd4vINdfjH6V2fHN1i9UYLA8pOWX6gXLu4T
vBZKStRJk+HyXJnqSG5b7BxguQo8JCVHsGfgab4hKkIiE3mZzBX+pRLPLG/krJaW
LPmGhIuJa/ujMFgA9nbAPjcOlH0x5NIea/jCpCLr3DwIPmRSsbIZvPkxhPiFqtyF
cGCtOdOhBkHNNfoF9tO/1ak4j6IBVVwr/4EPkBlRn1OnHMBNvOshFJj5zDrdr9VX
HKK8iOCpccpRqpwI6zdaLNxgvOthGEorGsXQwlQbLicsmPDZIpIseyH/T9C6eL50
BZghPtCXpD2tGZ1RxqWUt1IwA84tKSaKr+RQAy1Yoio0IxOXd7U0ljb4yIh+hhHt
YJQciA6MygBLFCsoe7u4
=IjX0
-END PGP SIGNATURE-







This message was sent using IMP, the Internet Messaging Program.