Re: SHELLOPTS=xtrace security hardening

[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: [PATCH/RFC] do not source/exec scripts on noexec mount points

[Mike Frysinger]

On 15 Dec 2015 06:47, konsolebox wrote:
> t On Mon, Dec 14, 2015 at 1:17 PM, Mike Frysinger  wrote:
> > On 13 Dec 2015 16:50, konsolebox wrote:
> >> On Sun, Dec 13, 2015 at 5:01 AM, Mike Frysinger wrote:
> >> > Today, if you have a script that lives on a noexec mount point, the
> >> > kernel will reject attempts to run it directly:
> >> >   $ printf '#!/bin/sh\necho hi\n' > /dev/shm/test.sh
> >> >   $ chmod a+rx /dev/shm/test.sh
> >> >   $ /dev/shm/test.sh
> >> >   bash: /dev/shm/test.sh: Permission denied
> >> >
> >> > But bash itself has no problem running this file:
> >> >   $ bash /dev/shm/test.sh
> >> >   hi
> >> > Or with letting other scripts run this file:
> >> >   $ bash -c '. /dev/shm/test.sh'
> >> >   hi
> >> > Or with reading the script from stdin:
> >> >   $ bash  >> >   hi
> >> >
> >> > This detracts from the security of the overall system.  People writing
> >> > scripts sometimes want to save/restore state (s) and will
> >> > restore the content from a noexec point using the aforementioned source
> >> > command without realizing that it executes code too.  Of course their
> >> > code is wrong, but it would be nice if the system would catch & reject
> >> > it explicitly to stave of inadvertent usage.
> >> >
> >> > This is not a perfect solution as it can still be worked around by
> >> > inlining the code itself:
> >> >   $ bash -c "$(cat /dev/shm/test.sh)"
> >> >   hi
> >> >
> >> > But this makes things a bit harder for malicious attackers (depending
> >> > how exactly they've managed to escalate), but it also helps developers
> >> > from getting it wrong in the first place.
> >>
> >> Application-level based security on an environment where people using
> >> the application has direct control over the environment for me is not
> >> so sensible, and is a dirty hack.  A shell is also not meant for that.
> >> If you want such feature perhaps you should add it on a restricted
> >> shell, granting it really makes sense adding it.  But forcing that
> >> feature to be default on every user (like me who doesn't want its
> >> inconsistency) is wrong.  A shell reads and executes and is something
> >> not in the scope of `noexec`, not in the scope of kernel-land
> >> security, so we have to deal with it.
> >
> > (1) the examples i already provided do not involve the user at all, and
> > include systems where the user has no direct access to the shell.
> 
> And the one that made the code execute remotely through for example an
> exploit is not a user?

you're conflating concepts, but still, the answer is no.  having a user
sitting at an interactive terminal and typing in commands or getting the
system to directly execute bash is not what i described.  systems that
do not permit access to any shells anywhere, and instead the attack is
breaking out of one process to write a text file somewhere that a diff
system/periodic process will later source.  you could get the same setup
as having a system you can only access over HTTP (i.e. no shell access)
and exploiting apache/php/whatever to write to a cache file that will be
read by another app.

i recall some router firmwares being attacked in this way -- a remote
bug only permitted the writing of data to common data locations, but
they picked a place where privileged init scripts would source saved
state.

> Also consider use of `source` or `eval` may it be in a subshell or not.

these cases have already been cited in this thread, and still are not
relevant to the scenarios described

> > (2) choice over runtime functionality is by the sysadmin, not the user.
> 
> Doesn't matter to me. And I'm referring to the real user or the
> person, and not the account. I don't want an inconsistent
> functionality running in my bash whether I'm using a privileged
> account or not.

it isn't inconsistent: no user gets to exec code from noexec points

> > (3) i disagree over the scope of noexec.  i think this is in-scope.
> 
> Being a little forgiving, I could say that scripts with #! headers
> -perhaps- are still in the scope of `noexec` since they are respected
> by the kernel as executables, even though they are not real
> instructions running within the processor's transistors themselves
> (they are just read and -virtually- executed where the shell acts on
> behalf of them), but how about those scripts without #! headers?
> Clearly they're no longer -executables-.  And clearly you're just
> wanting bash to restrict things based on the conceptual purpose of
> `noexec`, even though it is not exactly or strictly in the scope of
> `noexec`.  I'm a purist and I don't like that, and I don't want to
> have that inconsistency in default bash.

you're describing libraries which the kernel also blocks.  there's no
relevant difference between fragments you source and libraries that
ELF programs link against either directly (e.g. -lfoo) or indirectly
(e.g. dlopen(libfoo)).  the kernel blocks both as i described in my
first e-mail.
-mike


signature.asc

[patch] uniform bash loging

[Piotr Grzybowski]

Hi All,

 for some time I had been struggling with the logging system in my
scripts. I wanted it to automatically detect the status of last
executed command, print the customizable time stamp, work from within
functions, and so on. For me it took a couple of lines of echo, output
redirection, and if instructions to get what I wanted and needed.
 Then I created a log builtin, which I have cleaned now a much as I
could so the main idea is clear, and enclose as a diff against
bash-4.4-testing branched at 54a5fbe126d2a28913a81f7191d7ac6db70e1f43
.
 It is aimed at providing an uniform logging for bash. At the moment
it works as follows:

$ log "processing started."
[31867] Mon, 14 Dec 2015 12:32:41 +0100 processing started.

$ export LOG_FMT_HEADER="[ @%s %d-%m-%Y ]"
$ log "processing 10%."
[31867] [ @1450092818 14-12-2015 ] processing 10%.

$ function stat_file() { local stat; stat=`stat "${1}" 2>&1`; log
"getting status ($stat) ."; }
$ stat_file /tmp/it_is_here
[31867]stat_file [ @1450093235 14-12-2015 ] getting status (  File:
`/tmp/it_is_here'
  Size: 0   Blocks: 0  IO Block: 4096   regular empty file
Access: 2015-12-14 12:40:01.0 +0100
Modify: 2015-12-14 12:40:01.0 +0100
Change: 2015-12-14 12:40:01.0 +0100) .
$ stat_file /tmp/it_is_not_here
[31867]stat_file [ @1450093237 14-12-2015 ] error. getting status
(stat: cannot stat `/tmp/it_is_not_here': No such file or directory) .

$ unset LOG_FMT_HEADER
$ mkdir /tmp/it_is_not_here/directory 2>/dev/null; log "creating
directory." >/dev/null;
[31867] Mon, 14 Dec 2015 12:52:43 +0100 error. creating directory.

$ log "done." 2>/dev/null
[31867] Mon, 14 Dec 2015 12:53:46 +0100 done.

 I provide the diff so you can try it; it still needs lot of work and attention.
 What do you think?

cheers,
pg
commit 9ff927b1e30371cc462b40bf32cd99510679f7bd
Author: Peter Grzybowski 
Date:   Sun Dec 13 14:12:52 2015 +0100

log bulitin: uniform bash logging.

diff --git a/Makefile.in b/Makefile.in
index 5260a06..98d0ff5 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -491,7 +491,7 @@ BUILTIN_DEFS = $(DEFSRC)/alias.def $(DEFSRC)/bind.def 
$(DEFSRC)/break.def \
   $(DEFSRC)/exec.def $(DEFSRC)/exit.def $(DEFSRC)/fc.def \
   $(DEFSRC)/fg_bg.def $(DEFSRC)/hash.def $(DEFSRC)/help.def \
   $(DEFSRC)/history.def $(DEFSRC)/jobs.def $(DEFSRC)/kill.def \
-  $(DEFSRC)/let.def $(DEFSRC)/read.def $(DEFSRC)/return.def \
+  $(DEFSRC)/let.def $(DEFSRC)/log.def $(DEFSRC)/read.def 
$(DEFSRC)/return.def \
   $(DEFSRC)/set.def $(DEFSRC)/setattr.def $(DEFSRC)/shift.def \
   $(DEFSRC)/source.def $(DEFSRC)/suspend.def $(DEFSRC)/test.def \
   $(DEFSRC)/times.def $(DEFSRC)/trap.def $(DEFSRC)/type.def \
@@ -511,7 +511,7 @@ BUILTIN_OBJS = $(DEFDIR)/alias.o $(DEFDIR)/bind.o 
$(DEFDIR)/break.o \
   $(DEFDIR)/exec.o $(DEFDIR)/exit.o $(DEFDIR)/fc.o \
   $(DEFDIR)/fg_bg.o $(DEFDIR)/hash.o $(DEFDIR)/help.o \
   $(DEFDIR)/history.o $(DEFDIR)/jobs.o $(DEFDIR)/kill.o \
-  $(DEFDIR)/let.o $(DEFDIR)/pushd.o $(DEFDIR)/read.o \
+  $(DEFDIR)/let.o $(DEFDIR)/log.o $(DEFDIR)/pushd.o 
$(DEFDIR)/read.o \
   $(DEFDIR)/return.o $(DEFDIR)/shopt.o $(DEFDIR)/printf.o \
   $(DEFDIR)/set.o $(DEFDIR)/setattr.o $(DEFDIR)/shift.o \
   $(DEFDIR)/source.o $(DEFDIR)/suspend.o $(DEFDIR)/test.o \
@@ -1435,6 +1435,10 @@ builtins/let.o: command.h config.h 
${BASHINCDIR}/memalloc.h error.h general.h xm
 builtins/let.o: quit.h dispose_cmd.h make_cmd.h subst.h externs.h 
${BASHINCDIR}/stdc.h
 builtins/let.o: shell.h syntax.h bashjmp.h ${BASHINCDIR}/posixjmp.h sig.h 
unwind_prot.h variables.h arrayfunc.h conftypes.h 
 builtins/let.o: pathnames.h
+builtins/log.o: command.h config.h ${BASHINCDIR}/memalloc.h error.h general.h 
xmalloc.h ${BASHINCDIR}/maxpath.h
+builtins/log.o: shell.h syntax.h bashjmp.h ${BASHINCDIR}/posixjmp.h sig.h 
unwind_prot.h variables.h arrayfunc.h conftypes.h
+builtins/log.o: dispose_cmd.h make_cmd.h subst.h externs.h ${BASHINCDIR}/stdc.h
+builtins/log.o: $(DEFSRC)/common.h quit.h pathnames.h
 builtins/printf.o: config.h ${BASHINCDIR}/memalloc.h bashjmp.h command.h 
error.h
 builtins/printf.o: general.h xmalloc.h quit.h dispose_cmd.h make_cmd.h subst.h
 builtins/printf.o: externs.h sig.h pathnames.h shell.h syntax.h unwind_prot.h
@@ -1597,6 +1601,7 @@ builtins/inlib.o: $(DEFSRC)/inlib.def
 builtins/jobs.o: $(DEFSRC)/jobs.def
 builtins/kill.o: $(DEFSRC)/kill.def
 builtins/let.o: $(DEFSRC)/let.def
+builtins/log.o: $(DEFSRC)/log.def
 builtins/mapfile.o: $(DEFSRC)/mapfile.def
 builtins/pushd.o: $(DEFSRC)/pushd.def
 builtins/read.o: $(DEFSRC)/read.def
diff --git a/builtins/Makefile.in b/builtins/Makefile.in
index 19dd384..b6615e7 100644
--- a/builtins/Makefile.in
+++ b/builtins/Makefile.in
@@ -137,7 +137,7 @@ DEFSRC =  $(srcdir)/alias.def $(srcdir)/bind.def 

Re: Out of bounds heap read in function rl_tilde_expand

[Hanno Böck]

On Sat, 5 Dec 2015 16:19:55 -0500
Chet Ramey  wrote:

> > I've seen there was a new bash 4.3 patchlevel, but this one didn't
> > get fixed. Hope it wasn't forgotten.  
> 
> The fix is in the devel branch.

Okay. I assume it'll be some time till the devel branch becomes a new
release, so I had hoped this could find its way into 4.3. I think
invalid memory access is something that shouldn't happen in a stable
version.

(The reason I'm particularly interested in this is that I'm working on
making it easier to run a whole system with ASAN enabled - for that
these kind of issues need to be resolved.)

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42


pgpWUzLxhgpyE.pgp
Description: OpenPGP digital signature

Re: Ruler

[Greg Wooledge]

On Fri, Dec 11, 2015 at 08:41:26PM -0700, valkrem wrote:
> Assume I have a file named  "test"  and has three variables
> 
> Id Date  length
> 
> 123 20150518  2750 
> 125 20140324  3500
> 
> When I invoke  the command -ruler ( or  the script name)  I will see the 
> following
> 
> bash$ ruler test
> 12 3
> 12345678901234567890
> ---
> 123 20150518  2750 
> 125 20140324  3500

Your lines don't align, so I took the liberty of formatting the output
the way I saw fit.  Here's an alternative to Stephane's solution:

ruler() {
local cols=${COLUMNS:-$(tput cols)}
local i n tmp
if (( ${#_ruler_line1} < cols )); then
n=$(( ${#_ruler_line1} / 10 ))
for ((i=n+1; i*10 <= cols; i++)); do
printf -v tmp %10d "$i"
_ruler_line1+=$tmp
done
fi
while (( ${#_ruler_line2} < cols )); do
_ruler_line2+=1234567890
done
echo "${_ruler_line1:0:cols}"
echo "${_ruler_line2:0:cols}"
cat "$@"
}

It could be done as a script instead of a function, but the function
version keeps _ruler_line1 and _ruler_line2 around as global variables
so it doesn't have to recreate them every time.  It simply appends to
them whenever the terminal width increases.

Re: SHELLOPTS=xtrace security hardening

[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

[Stephane Chazelas]

2015-12-14 18:01:13 +0100, up201407...@alunos.dcc.fc.up.pt:
[...]
> 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.
[...]

Should we also stop importing BASH_ENV in case some suid
application executes a bash script after having done a
setuid(0)? 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).

Shall we have bash stop importing BASHOPTS and SHELLOPTS
actually as most options would affect the behaviour of bash (and
sh on those systems where sh is bash) scripts called by those
broken applications, or CDPATH?

Shall we have python stop importing PYTHONPATH, perl PERL5LIB as
that would also allow ACE for python/perl scripts called by
those broken applications?

My /bin/date is a zsh wrapper script around GNU date, should we
have zsh stop using $HOME and $ZDOTDIR to lookup its ~/.zshenv?

-- 
Stephane

Re: [PATCH] Support configurable mode strings in prompt

[Chet Ramey]

On 12/6/15 10:34 PM, Dylan Cali wrote:
> 
> On Sun, Nov 16, 2014 at 9:48 PM, Chet Ramey  > wrote:
> 
> Most of this will be in the next release of bash.  I added some things and
> left out the \m prompt expansion for now.
> 
> 
> Hi Chet,
> 
> I finally had a chance to play with the 4.4 beta.  Unfortunately, it seems
> to be getting confused when color escapes are used (getting a lot of
> garbage when I switch to command mode).  These are the mode strings I used
> (just the defaults with green/yellow color escapes):
> 
> set vi-ins-mode-string   \1\e[32;1m\2(ins)\1\e[0m\2
> set vi-cmd-mode-string \1\e[33;1m\2(cmd)\1\e[0m\2

Thanks for the report.  The problem involved redrawing only the changed
portion of the prompt string (which is what readline's redisplay does by
default).  When the first differing character appears in a portion of the
prompt that is bracketed by non-printable characters, you have to redraw
the entire prompt to make sure that all the escape sequences are output.

Chet
-- 
``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: [PATCH/RFC] do not source/exec scripts on noexec mount points

[konsolebox]

t On Mon, Dec 14, 2015 at 1:17 PM, Mike Frysinger  wrote:
> On 13 Dec 2015 16:50, konsolebox wrote:
>> On Sun, Dec 13, 2015 at 5:01 AM, Mike Frysinger wrote:
>> > Today, if you have a script that lives on a noexec mount point, the
>> > kernel will reject attempts to run it directly:
>> >   $ printf '#!/bin/sh\necho hi\n' > /dev/shm/test.sh
>> >   $ chmod a+rx /dev/shm/test.sh
>> >   $ /dev/shm/test.sh
>> >   bash: /dev/shm/test.sh: Permission denied
>> >
>> > But bash itself has no problem running this file:
>> >   $ bash /dev/shm/test.sh
>> >   hi
>> > Or with letting other scripts run this file:
>> >   $ bash -c '. /dev/shm/test.sh'
>> >   hi
>> > Or with reading the script from stdin:
>> >   $ bash > >   hi
>> >
>> > This detracts from the security of the overall system.  People writing
>> > scripts sometimes want to save/restore state (s) and will
>> > restore the content from a noexec point using the aforementioned source
>> > command without realizing that it executes code too.  Of course their
>> > code is wrong, but it would be nice if the system would catch & reject
>> > it explicitly to stave of inadvertent usage.
>> >
>> > This is not a perfect solution as it can still be worked around by
>> > inlining the code itself:
>> >   $ bash -c "$(cat /dev/shm/test.sh)"
>> >   hi
>> >
>> > But this makes things a bit harder for malicious attackers (depending
>> > how exactly they've managed to escalate), but it also helps developers
>> > from getting it wrong in the first place.
>>
>> Application-level based security on an environment where people using
>> the application has direct control over the environment for me is not
>> so sensible, and is a dirty hack.  A shell is also not meant for that.
>> If you want such feature perhaps you should add it on a restricted
>> shell, granting it really makes sense adding it.  But forcing that
>> feature to be default on every user (like me who doesn't want its
>> inconsistency) is wrong.  A shell reads and executes and is something
>> not in the scope of `noexec`, not in the scope of kernel-land
>> security, so we have to deal with it.
>
> (1) the examples i already provided do not involve the user at all, and
> include systems where the user has no direct access to the shell.

And the one that made the code execute remotely through for example an
exploit is not a user? Also consider use of `source` or `eval` may it
be in a subshell or not.

eval "$(cat /path/script.sh)"
source <(cat /path/script.sh)

> (2) choice over runtime functionality is by the sysadmin, not the user.

Doesn't matter to me. And I'm referring to the real user or the
person, and not the account. I don't want an inconsistent
functionality running in my bash whether I'm using a privileged
account or not.

> (3) i disagree over the scope of noexec.  i think this is in-scope.

Being a little forgiving, I could say that scripts with #! headers
-perhaps- are still in the scope of `noexec` since they are respected
by the kernel as executables, even though they are not real
instructions running within the processor's transistors themselves
(they are just read and -virtually- executed where the shell acts on
behalf of them), but how about those scripts without #! headers?
Clearly they're no longer -executables-.  And clearly you're just
wanting bash to restrict things based on the conceptual purpose of
`noexec`, even though it is not exactly or strictly in the scope of
`noexec`.  I'm a purist and I don't like that, and I don't want to
have that inconsistency in default bash.