Re: Arbitrary command execution in shell - by design!
On 2021-10-29 at 22:41 -0700, L A Walsh wrote: > > This is quite unfair. > Huh? It's true--look at how functions have to be stored in > the environment because someone was able to hack "their > own system" where they already have unrestricted shell access. > > If that isn't ugly or lame, what is? But it was the fault > of taking actions that a hacker could do on a system where > they already had shell access to corrupt their own environment. No. The big issue was that web servers convert HTTP headers into environment variables when calling a CGI script (adding a HTTP_ prefix which didn't help here), but that allowing a *remote* user to set certain environment variables that lead to execution if the CGI itself was a shell script run under bash or bash got called from it. Two features were safe when taken separately, but turned out to be dangerous when combined. A bug that is only self-exploitable isn't really a security issue. > If permissions and paths were correctly set to never execute > files owned by that user, I don't see how that exploit > would gain root access and affect anyone other the user > who was injecting the code into their own function. That exploit didn't allow escalating to root (by itself). It would typically allow execution as a web user (www-data, apache…) or the owner of the CGI file. Escalation to root would need to be a separate step. Regards
Re: Arbitrary command execution in shell - by design!
Le 30/10/2021 à 07:41, L A Walsh écrivait : On 2021/10/29 12:33, Greg Wooledge wrote: On Fri, Oct 29, 2021 at 11:59:02AM -0700, L A Walsh wrote: How much lameness Chet has introduced into bash to accommodate the wrong users. This is quite unfair. Huh? It's true--look at how functions have to be stored in the environment because someone was able to hack "their own system" where they already have unrestricted shell access. ... Expect to see more of those misplaced security rants now that Bash becomes popular with git-bash and bash in Windows environment. Indeed, if a bash script is able to be abused, it is not bash's fault, neither the script's fault, but the system's security policies granting those privileges to the user running the script. -- Léa Gris
Re: Arbitrary command execution in shell - by design!
On 2021/10/29 12:33, Greg Wooledge wrote: On Fri, Oct 29, 2021 at 11:59:02AM -0700, L A Walsh wrote: How much lameness Chet has introduced into bash to accommodate the wrong users. This is quite unfair. Huh? It's true--look at how functions have to be stored in the environment because someone was able to hack "their own system" where they already have unrestricted shell access. If that isn't ugly or lame, what is? But it was the fault of taking actions that a hacker could do on a system where they already had shell access to corrupt their own environment. If permissions and paths were correctly set to never execute files owned by that user, I don't see how that exploit would gain root access and affect anyone other the user who was injecting the code into their own function. Asking how much lameness Chet had to introduce, says nothing about fault. Think about functions and how they look in the environment. I never thought those things were a mis-design in bash, but an abuse by people who shouldn't have access to the system they supposedly could exploit. There was nothing wrong with functions on a system where the only shell user was one's self. Giving shell access to untrusted people is a problem of a specific system's security "policy". I don't bash functions should have been hacked to try to disable malformed functions as introduced from the environment. It may be true that doing so gives a site using bash better defense from attackers, but functions were not at fault -- since for the malicious user -- they need access to the system shell to use their exploit. If you give out shell access in a stock unix/linux system, it has generally been considered you've given up a large part of your security. Maybe if your system has mandatory security features like FLASK, Windows mandatory integrity labeling, SMAC (linux security option), where getting root doesn't equal game over, then it might be possible to allow shell access "in general", but the unix/linux shell was designed for a time of trusted users on a relatively closed or private academic system where the focus was on making things easier, not needing to post guards at every port, etc. There have been other similar bugs (that weren't really bugs) involving symlinks that the hacker could "magically" place in root's path (right...), or in samba -- where using linux extensions on a linux-based file server, one could create symlinks on a system where samba "widelinks" were enabled to allow symlinks to be followed across partitions (but only on partitions where widelinks were enabled and if the user was able to use samba-extended features on a particular Share. People threw a hissy fit, but a minority of samba users (self included) didn't see it as a problem since our security policy gave shell access to users (mainly me & few others) who had "shares" on the linux-based domain server. I.e. anything the user could do with samba they could do in the server's shell which they could also log into. I use my linux server as an extension to my desktop, so full access isn't a big deal. But in Windows, it is far more rare to let users have server-shell access to the servers their users import shares from. Their security policy didn't allow for users having server access, so that a user could control the links on the server was a problem. I suggested the name for the feature 'allow user controlled symlinks' or something similar. The samba folks eventually re-enabled the feature under the name "allow-insecure-widelinks"*bleh*. Most inelegant. It's that type of inelegance that had to be inserted into bash to make bash more secure in an unsecure environment that I refer to. If someone wants to hack their own shell, so what? I'm just not going to let them write shell scripts for me.
Re: Arbitrary command execution in shell - by design!
Date:Fri, 29 Oct 2021 11:59:02 -0700 From:L A Walsh Message-ID: <617c4476.2010...@tlinx.org> | Bash is a command_line console language designed to execute commands | locally in the context of the user. Local user access to a console, | from a security standpoint, is generally equated with root-access, | game over as far as being secure. Sorry, but this, and everything that follows from this, is utter nonsense. Once upon a time (back when shells were invented) all command access was via a shell, on the console (not necessarily by a user with root privs, though console access on some systems needed to be restricted for other reasons - depends upon the way the hardware works) or on some other terminal connected to the system. There were no GUIs. There were no terminals capable of displaying anything other that text. In the beginning, all terminals printed on paper. Bash is a (slightly more recent than that, but not all that much) implementation of such a shell (with a whole bunch of extensions added over what was in the initial shells ... some of them, IMO, very useful, some of them a complete waste of space (again, IMO)). Any thought that only root users use shells is simply absurd. | People have the wrong expectations, | if they expect the 'language that allows you all-access to your machine' | to be 'secure' when random users are permitted to use it. The shell is a multi-purpose language - it only allows "all-access" when the privileges of the user permit execution of privileged commands. There is absolutely nothing in the shell itself (including bash and all its extensions, similarly ksh93, or zsh, other wildly extended shells) which grants any kind of privileged access whatever. It is perfectly safe for anyone to run any normal shell script, they cannot do that way anything they could not do any other way. Where there can be issues, is when a script being run by one user accepts input by another (running scripts on one system using data received over a network connection is the obvious example of this, but there are others) is where extreme caution is needed. kre
Re: Arbitrary command execution in shell - by design!
on 29/10/2021 at 21:33, Greg Wooledge wrote : Making bash *less horrible* to use for programming purposes doesn't qualify as "lameness" in my book. Even if it does "enable" people to use shells for unsuited purposes, I'd still much rather have indexed and associative arrays (bash) than not have them at all (sh). There are several *suitable* tasks for which they are immensely useful. So much good words Greg. And many thanks to you for your valuable Wiki. Thank you for giving credit where credit is due. If you think there might be security concerns, beyond genuine human errors, this is a red flag to avoid shell scripts and find a more suitable language/tool for this task. -- Léa Gris
Re: Arbitrary command execution in shell - by design!
On Fri, Oct 29, 2021 at 11:59:02AM -0700, L A Walsh wrote: > How much lameness Chett has introduced into bash to accommodate > the wrong users. This is quite unfair. The major systemic problems with bash (and sh) weren't introduced by Chet Ramey. They've been baked in from the very beginning. Making bash *less horrible* to use for programming purposes doesn't qualify as "lameness" in my book. Even if it does "enable" people to use shells for unsuited purposes, I'd still much rather have indexed and associative arrays (bash) than not have them at all (sh). There are several *suitable* tasks for which they are immensely useful.
Re: Arbitrary command execution in shell - by design!
On 2021/10/29 05:01, Greg Wooledge wrote: On Fri, Oct 29, 2021 at 12:48:57PM +0300, Ilkka Virta wrote: Not that I'm sure the upper one is still safe against every input. I think issues with associative array keys have been discussed on the list before. Sadly, yes. Bash is the exploding barbed wire death match of programming languages. Every single feature of bash is capable of hurting you if you use it in the naive or obvious way. Bash is a command_line console language designed to execute commands locally in the context of the user. Local user access to a console, from a security standpoint, is generally equated with root-access, game over as far as being secure. People have the wrong expectations, if they expect the 'language that allows you all-access to your machine' to be 'secure' when random users are permitted to use it. Perl was developed with features that encompass the commands in shell with facilities (like taint) that help the developer to catch mis-use of raw-environment (including user) input. If you need to develop a script for generic-untrusted third parties, a shell-script of any sort is not a good solution. Shell is good for non-malicious control of local system events. As soon as anyone untrusted can execute a shell script or has generic shell access, you have lost system security. Stop blaming and shaming shell for doing what it was intended to do by using it in a hostile-user environment. If you aren't smart enough to choose the right language for a given purpose, then you need to hire a trained programmer who does. Note -- universities train computer scientists in design -- like collecting requirements (including security) and making decisions for further development. That doesn't mean all graduates are equal. Experience helps, but experience w/o any context in theory, context, and what has been done before is very often wasted. Note -- perl isn't a panacea. It was developed as a tool, but is, in its later life, being randomly changed to suite the wants of its current set of developers (some who think documentation is the same thing as code, and that the perl language should read the documentation of those who write extensions, modules or packages). I wouldn't personally recommend using a perl > 5.16.3, since with 5.18 and above, various incompatibilities with older perls were (and are being) introduced. Also, note, python isn't a shell-scripting language. It may be getting popular, but it was designed more for applications than for operating system control. It's more of a learning-language -- and is being increasing used for such to replace 'pascal' -- another teaching language that has been historically used in schools. But stop thinking bash has security bugs because it lets users (who have shell access and arbitrary root access to their machine to "do things". Because that's what it was designed for. How much lameness Chett has introduced into bash to accommodate the wrong users.
