Re: Arbitrary command execution in shell - by design!

[L A Walsh]

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.