Re: [PATCH/RFC] do not source/exec scripts on noexec mount points
On Sun, Dec 13, 2015 at 5:01 AM, Mike Frysinger wrote: > From: Mike Frysinger > > 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: > $ bashhi > > This detracts from the security of the overall system. People writing > scripts sometimes want to save/restore state (like variables) 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.
Re: [PATCH/RFC] do not source/exec scripts on noexec mount points
hi, On Sat, Dec 12, 2015 at 11:53 PM, Mike Frysinger wrote: > On 12 Dec 2015 15:06, Bob Proulx wrote: >> It will almost >> certainly get in the way of a reasonable use case. > > can you name a reasonable use case this breaks ? source /media/noexecmountpoint/sh/functions.sh; find_all_files_with_executable_bit /media/noexecmountpoint; Mike: I kind of understand your idea, but noexec flag given in the mount significates something else then your patch addresses. cheers, pg
Re: [PATCH/RFC] do not source/exec scripts on noexec mount points
2015-12-12 16:01:26 -0500, Mike Frysinger: [...] > 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 Or cat /dev/shm/test.sh | bash I think this kind of hardening is better left to things like selinux/apparmor. -- Stephane
Re: [PATCH/RFC] do not source/exec scripts on noexec mount points
2015-12-12 17:53:35 -0500, Mike Frysinger: [...] > > It will almost > > certainly get in the way of a reasonable use case. > > can you name a reasonable use case this breaks ? bash << EOF some code EOF here-documents with many shells (including bash) are implemented as deleted temporary files (typically in /tmp which sometimes has noexec). -- Stephane
Re: Ruler
Stepahne, How do I use it? I am just a starter for linux commands -- View this message in context: http://gnu-bash.2382.n7.nabble.com/Ruler-tp16609p16614.html Sent from the Gnu - Bash mailing list archive at Nabble.com.
Re: SHELLOPTS=xtrace security hardening
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. 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. 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. -- ``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 "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-13 12:49:58 -0500, Chet Ramey:
[...]
> 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.
[...]
In the (very specific) OP's test case, he had
system("/bin/date"). Since /bin/date doesn't usually execute
other commands, PATH won't help.
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.
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.
What bash could do is document what environment variables affect
its behaviour (so setuid applications know which to sanitize),
but that's mostly already done and anyway, the proper way to
sanitize the environment is not to blacklist known troublesome
env vars (what about the unknown ones?) but to clear everything
except the ones you need (and still check and sanitize their
content).
The environment is meant to be used like that. It's meant to be
trusted. Setuid applications fail their contract if they fail to
sanitize the environment before running other applications.
--
Stephane
Re: [PATCH/RFC] do not source/exec scripts on noexec mount points
On 12/12/15 4:01 PM, Mike Frysinger wrote: > From: Mike Frysinger > > 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: It's hard to see how this proposal improves overall system security. There are a dozen ways a minimally-competent attacker can circumvent it. Unless you want to completely remove the ability for bash and other utilities to read files from a noexec file system, or run on a system with no writable file systems at all, this does no good. Its primary effect would seem to be annoying and frustrating users. A worse problem is that the abstraction is in the wrong place. The shell, like other programs, requests services from the kernel to do things. The kernel is the arbiter of restrictions on those services. If asked to execute a file, the shell asks the kernel whether the file is executable, then tries to execute it. If asked to read a file, the shell tries to open it. The kernel, or some agent it invokes, is where the access decision is made. If you want to, for instance, disallow the shell and other utilities from opening executable files for reading on file systems with noexec set, the shell binary is not the place to embed that policy. 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
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 (like variables) 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. (2) choice over runtime functionality is by the sysadmin, not the user. (3) i disagree over the scope of noexec. i think this is in-scope. -mike signature.asc Description: Digital signature
Re: [PATCH/RFC] do not source/exec scripts on noexec mount points
On 12 Dec 2015 23:05, Stephane Chazelas wrote: > 2015-12-12 16:01:26 -0500, Mike Frysinger: > [...] > > 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 > > Or > > cat /dev/shm/test.sh | bash right, there's no way to look through pipes > I think this kind of hardening is better left to things like > selinux/apparmor. security is not an all-or-nothing proposotion. the whole point is to have defence in depth. -mike signature.asc Description: Digital signature
Re: [PATCH/RFC] do not source/exec scripts on noexec mount points
On 13 Dec 2015 12:21, Piotr Grzybowski wrote: > On Sat, Dec 12, 2015 at 11:53 PM, Mike Frysinger wrote: > > On 12 Dec 2015 15:06, Bob Proulx wrote: > >> It will almost > >> certainly get in the way of a reasonable use case. > > > > can you name a reasonable use case this breaks ? > > source /media/noexecmountpoint/sh/functions.sh; > find_all_files_with_executable_bit /media/noexecmountpoint; i think you're doing it wrong. if you want to run code off of mount point, then you should be mounting it executable. > Mike: I kind of understand your idea, but noexec flag given in the > mount significates something else then your patch addresses. i disagree -mike signature.asc Description: Digital signature
Re: [PATCH/RFC] do not source/exec scripts on noexec mount points
On 13 Dec 2015 17:24, Chet Ramey wrote: > On 12/12/15 4:01 PM, 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: > > It's hard to see how this proposal improves overall system security. There > are a dozen ways a minimally-competent attacker can circumvent it. you're assuming the attacker has unlimited access to resources and control over the environment and execution. i already noted there are ways to run arbitrary code -- when you have arbitrary code access. there also are cases (such as i described) which this change would block attacks because the attacker does not have such unfettered access. they're leveraging a small bug elsewhere to escalate to a fuller environment. > Unless > you want to completely remove the ability for bash and other utilities to > read files from a noexec file system, or run on a system with no writable > file systems at all, this does no good. Its primary effect would seem to > be annoying and frustrating users. > > A worse problem is that the abstraction is in the wrong place. The shell, > like other programs, requests services from the kernel to do things. The > kernel is the arbiter of restrictions on those services. If asked to > execute a file, the shell asks the kernel whether the file is executable, > then tries to execute it. If asked to read a file, the shell tries to > open it. The kernel, or some agent it invokes, is where the access > decision is made. If you want to, for instance, disallow the shell and > other utilities from opening executable files for reading on file systems > with noexec set, the shell binary is not the place to embed that policy. i'm aware of the fundamental structure of UNIX-like systems. bash itself is providing services to a program by executing the requested code and in a sense, has a responsibility to control that. otherwise, you seem to be arguing against the existence of rbash, or job control, or similar shell limiting/control functionality. i understand this is a disruptive change. how about making it a compile time flag, or perhaps a new shopt ? -mike signature.asc Description: Digital signature
Re: Bash crash
Hey, we have had an off--list discussion with Kai on this (to shorten the 30 mails we exchanged ;-) I am writing this summary). He solved the issue by --without-bash-malloc which could indicate a bug or lack of proper support in lib/malloc/malloc.c for his platform. However, we were unable to get more information, it is not that easy to reproduce. If there is no one who can reproduce this we can try again, if you think it is worthwhile. For now, if anyone bumps into this, try, according to Kai findings, configure with --without-bash-malloc cheers, pg On Tue, Oct 20, 2015 at 3:31 PM, Chet Ramey wrote: > On 10/19/15 10:47 PM, Kai Wang X wrote: >> Dear, >> >> >> >> We have two products which are using bash 4.2 and 4.3 separately. They all >> meet bash crash issue. Please refer to the attached files. >> >> It is hard for me to understand the bash source code to find the root cause >> out. > > It really looks like sbrk(2) is failing here, but since I don't have > any way to reproduce it, that may not be it. This could be caused by > your process exceeding its memory resource limit or your system's swap > space being exhausted. > > 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/ >
