feature request: store lines before history expansion
Hello! I would appreciate if bash could optionally (some option – on by default when histexpand is set) store the command line *before* history expansion additionally to expanded line. Regards, Hans
Re: feature request: store lines before history expansion
On 12/10/15, Hans Ginzel wrote: > Hello! > > I would appreciate if bash could optionally > (some option – on by default when histexpand is set) > store the command line *before* history expansion > additionally to expanded line. > > Regards, > Hans > Just curious, why? --- xoxo iza
SHELLOPTS=xtrace security hardening
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: feature request: store lines before history expansion
On 12/10/15 11:04 AM, Hans Ginzel wrote: > Hello! > > I would appreciate if bash could optionally > (some option – on by default when histexpand is set) > store the command line *before* history expansion > additionally to expanded line. Store it where? In this history list? Why? -- ``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/
Re: SHELLOPTS=xtrace security hardening
2015-12-10 20:16:49 +0100, 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.
[...]
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.
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.
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.
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.
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.
--
Stephane
Re: [PATCH] `alias' reusable form breaks with alias NAMES starting with `-'
On 12/9/15 8:11 PM, Mingye Wang (Arthur2e5) wrote: > Bash Version: 4.3 > Patch Level: 42 > > Description: > `alias' does not `--'-ize alias items with a name starting with a `-' > when it is invoked to print aliases in the reusable form. This causes > `invalid option' errors when trying to reuse these output. This was changed back in March, and the change was in bash-4.4-alpha. -- ``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/
