Re: [PATCH/RFC] do not source/exec scripts on noexec mount points
On Tue, Dec 15, 2015 at 7:30 AM, Mike Frysinger wrote: > 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. Ok I accept your point. So it's actually about `source` and `bash file`, correct? So would this mean every script I `source` would need +x bit now? And if it's not about the +x bit and only about `noexec`, would stuff I place that I would want to not execute (with execve(), etc.) in a `noexec` directory no longer be `source`-able, even though I'm still wanting those to be `source`-d? `source` is meant to only require readable permission. >> > (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 You complicate it. I'm both a user and an administrator to my personal system and I don't want that function running by default in my bash. Simple. >> > (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 r
Re: SHELLOPTS=xtrace security hardening
2015-12-15 00:30:16 +0100, up201407...@alunos.dcc.fc.up.pt: [...] > >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? [...] 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. And if HISTFILE is for instance a /proc/$pid/fd/$fd which identifies the reading end of a pipe (like for instance the pipes used by sshd), then you're going to have root read the content of that pipe under the feet of the process that content was intended to, causing at best a DoS. Same for /dev/pts/x or some /dev/input/x. Your example had the same problem with $TZ. sudo sanitizes $TZ (http://www.sudo.ws/alerts/tz.html) and blocks SHELLOPTS and PS4 even when env_reset is unset. If a bash script called in that context calls "read -e", that allows reading arbitrary files (read -e allows executing any command via shell-expand-line anyway). -- Stephane
Re: SHELLOPTS=xtrace security hardening
On 12/14/15 6:30 PM, up201407...@alunos.dcc.fc.up.pt wrote: > 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. Maybe if running with uid 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). > > Mind explaining this one? > I can't seem to write to HISTFILE in a non-interactive shell, or am i > missing something? 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. -- ``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/
rewriting a readonly var should exit
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../. -I.././include -I.././lib -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall uname output: Linux clamavsig1 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u6 (2015-11-09) x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.3 Patch Level: 30 Release Status: release Description: in the posix shell specification [1] when a script tries to to overwrite a readonly variable it should crash the script. Repeat-By: #!/bin/bash readonly rovar="goodvalue" rovar="badvalue" echo "You should not see this message" Fix: the bash interpreter should exit when the readonly var is being asked for an overwrite [1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_08_01 -- Aurelien Domain Name Registrar \o/ Hosting For Geeks and more... Gandi.net No Bullshit ! signature.asc Description: OpenPGP digital signature
Re: rewriting a readonly var should exit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/15/15 6:12 AM, Aurelien ROUGEMONT wrote: > Bash Version: 4.3 > Patch Level: 30 > Release Status: release > > Description: > in the posix shell specification [1] when a script tries to to > overwrite a readonly variable it should crash the script. > > Repeat-By: > #!/bin/bash > readonly rovar="goodvalue" > rovar="badvalue" > echo "You should not see this message" > > Fix: > the bash interpreter should exit when the readonly var is being asked > for an overwrite The shell exits in this case when it is running in Posix mode. - -- ``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/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlZwI7IACgkQu1hp8GTqdKsyxACgk42MVS+jQeKSxZ6IoKQu0yaZ ZDoAn3HrbC7JYivv3fOIS1akKf2XNFkh =18vR -END PGP SIGNATURE-
Re: rewriting a readonly var should exit
Are you running BASH in POSIX mode? That's a option. Example: [tsh009@it-johnmckown-linux junk]$ cat ro.sh #!/bin/bash readonly x="x" x="y" echo "sno" [tsh009@it-johnmckown-linux junk]$ ./ro.sh ./ro.sh: line 3: x: readonly variable sno [tsh009@it-johnmckown-linux junk]$ vim ro.sh [tsh009@it-johnmckown-linux junk]$ cat ro.sh #!/bin/bash set -o posix readonly x="x" x="y" echo "sno" [tsh009@it-johnmckown-linux junk]$ ./ro.sh ./ro.sh: line 4: x: readonly variable [tsh009@it-johnmckown-linux junk]$ On Tue, Dec 15, 2015 at 5:12 AM, Aurelien ROUGEMONT wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' > -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' > -DSHELL -DHAVE_CONFIG_H -I. -I../. -I.././include -I.././lib > -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat > -Werror=format-security -Wall > uname output: Linux clamavsig1 3.16.0-4-amd64 #1 SMP Debian > 3.16.7-ckt11-1+deb8u6 (2015-11-09) x86_64 GNU/Linux > Machine Type: x86_64-pc-linux-gnu > > Bash Version: 4.3 > Patch Level: 30 > Release Status: release > > Description: > in the posix shell specification [1] when a script tries to to > overwrite a readonly variable it should crash the script. > > Repeat-By: > #!/bin/bash > readonly rovar="goodvalue" > rovar="badvalue" > echo "You should not see this message" > > Fix: > the bash interpreter should exit when the readonly var is being > asked > for an overwrite > > > > [1] > > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_08_01 > > > > -- > Aurelien Domain Name Registrar >\o/ Hosting For Geeks and more... > Gandi.net No Bullshit ! > > -- Schrodinger's backup: The condition of any backup is unknown until a restore is attempted. Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be. He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! <>< John McKown
Re: rewriting a readonly var should exit
Aurelien ROUGEMONT writes: > Description: > in the posix shell specification [1] when a script tries to to > overwrite a readonly variable it should crash the script. > > Repeat-By: > #!/bin/bash > readonly rovar="goodvalue" > rovar="badvalue" > echo "You should not see this message" You are not running the shell in posix mode. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: rewriting a readonly var should exit
On 12/15/2015 03:39 PM, Andreas Schwab wrote: > Aurelien ROUGEMONT writes: > >> Description: >> in the posix shell specification [1] when a script tries to to >> overwrite a readonly variable it should crash the script. >> >> Repeat-By: >> #!/bin/bash >> readonly rovar="goodvalue" >> rovar="badvalue" >> echo "You should not see this message" > > You are not running the shell in posix mode. > > Andreas. > Oh true. sorry about the noise then. thought bash would behave the same as sh/dash/manyothersihavetested. Nevermind Thanks for the feedback. -- Aurelien Domain Name Registrar \o/ Hosting For Geeks and more... Gandi.net No Bullshit ! signature.asc Description: OpenPGP digital signature
Re: SHELLOPTS=xtrace security hardening
2015-12-15 09:01:05 -0500, Chet Ramey: [...] > > Mind explaining this one? > > I can't seem to write to HISTFILE in a non-interactive shell, or am i > > missing something? > > 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. [...] BTW: $ bash -o history -o histexpand -c 'echo !!' !! $ bash -o history -o histexpand <<< 'echo !!' !! $ SHELLOPTS=history:histexpand bash -c 'echo !!' !! $ SHELLOPTS=history:histexpand bash <<< 'echo !!' bash: line 1: !!: event not found $ SHELLOPTS=history:histexpand bash <(<<<'echo !!') /proc/self/fd/11: line 1: !!: event not found $ bash -o history -o histexpand <(<<< 'echo !!') !! (also note that when there is an error, the exit status is 0) -- Stephane
Re: SHELLOPTS=xtrace security hardening
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
On 12/15/15 12:33 PM, Stephane Chazelas wrote: > 2015-12-15 09:01:05 -0500, Chet Ramey: >> On 12/14/15 6:30 PM, up201407...@alunos.dcc.fc.up.pt wrote: >>> 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. >> >> Maybe if running with uid 0. > [...] > > FWIW, my use case for SHELLOPTS=xtrace is often for uid 0: Which should not be affected by what we're talking about, which is not importing PS4 from the environment when uid == 0. -- ``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
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' -- ``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
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-15 09:01:05 -0500, Chet Ramey: > On 12/14/15 6:30 PM, up201407...@alunos.dcc.fc.up.pt wrote: > > 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. > > Maybe if running with uid 0. [...] FWIW, my use case for SHELLOPTS=xtrace is often for uid 0: SHELLOPTS=xtrace dpkg -i file.deb (debug installation scripts) SHELLOPTS=xtrace grub-install /dev/vda ... (Blocking PS4 and not SHELLOPTS=xtrace would work for me in that regard). -- Stephane
Re: SHELLOPTS=xtrace security hardening
On 12/15/15 10:40 AM, Stephane Chazelas wrote: > 2015-12-15 09:01:05 -0500, Chet Ramey: > [...] >>> Mind explaining this one? >>> I can't seem to write to HISTFILE in a non-interactive shell, or am i >>> missing something? >> >> 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. > [...] > > BTW: > > $ bash -o history -o histexpand -c 'echo !!' > !! Thanks, I'll take a look. It works when run as a script. -- ``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/
