Re: [RFC PATCH v19 0/5] Script execution control (was O_MAYEXEC)

[Mickaël Salaün]

On Wed, Jul 17, 2024 at 01:59:22PM -0400, Boris Lukashev wrote:
> Apologies, sent from phone so plain-text wasn't flying.
> To elaborate a bit on the quick commentary there - i'm the happy
> camper behind most of the SSL shells, SSH stuff, AWS shells, and so on
> in Metasploit. So please take the following with a grain of
> tinfoil-hat salt as i'm well aware that there is no perfect defense
> against these things which covers all bases while permitting any level
> of sane operation in a general-purpose linux system (also work w/
> GrapheneOS which is a far more suitable context for this sort of
> thing). Having loosely followed the discussion thread, my offsec-brain
> $0.02 are:
> 
> Shells are the provenance of the post-exploitation world - it's what
> we want to get as a result of the exploit succeeding. So i think we
> want to keep clear delineation between exploit and post-exp mitigation
> as they're actually separate concerns of the killchain.

Indeed.  The goal of this patch series is to control executable code, so
mostly to make exploitation more difficult. When an attacker can execute
code (e.g. with ROP), execution control is already bypassed.

> 1. Command shells tend to differentiate from interpreted or binary
> execution environments in their use of POSIX file descriptor
> primitives such as pipes. How those are marshalled, chained, and
> maintained (in a loop or whatever, hiding args, etc) are the only real
> IOCs available at this tier for interdiction as observation of data
> flow through the pipes is too onerous and complex.

I agree. Only files can reliably be inspected.

> Target systems vary
> in the post-exp surfaces exposed (/dev/tcp for example) with the
> mechanics of that exposure necessitating adaptation of marshalling,
> chaining, and maintenance to fit the environment; but the basic
> premise of what forms a command shell cannot be mitigated without
> breaking POSIX mechanics themselves - offsec devs are no different
> from anyone else, we want our code to utilize architectural primitives
> instead of undefined behavior for longevity and ecosystem
> persistence/relevance.
> 2. The conversation about interpreted languages is probably a dead-end
> unless you want to neuter the interpreter - check out Spencer
> McIntyre's work re Python meterpreter or HDs/mine/etc on the PHP side.
> The stagers, loaded contexts, execution patterns, etc are all
> trivially modified to avoid detection (private versions not submitted
> for free ripping by lazy commercial entities to the FOSS ecosystem,
> yet). Dynamic code loading of interpreted languages is trivial and
> requires no syscalls, just text/serialized IL/etc. The complexity of
> loaded context available permits much more advanced functionality than
> we get in most basic command interpreter shells - <advanced evasions
> go here before doing something that'll get you caught> sort of thing.

Right, if attackers can bring their own code (or even do ROP), it
doesn't matter what it interprets, its arbitrary code execution.

> 3. Lastly, binary payloads such as Mettle have their own advantages re
> portability, skipping over libc, etc but need to be "harnessed-in"
> from say a command-injection exploit via memfd or similar. We haven't
> published our memfd stagers while the relevant sysctl gets adopted
> more widely, but we've had them for a long time (meaning real bad guys
> have as well) and have other ways to get binary content into
> executable memory or make memory containing it executable
> (to-the-gills Grsec/PaX systems notwithstanding). IMO, interdiction of
> the harnessed injection from a command context is the last time when
> anything of use can be done at this layer unless we're sure that we
> can trace all related and potentially async (not within the process
> tree anyway) syscalls emanating from what happens next. Subsequent
> actions are separate "remedial" workflows which is a wholly separate
> philosophical discussion about how to handle having been compromised
> already.

Indeed, there are some prerequisites for a secure system.  In this case
we trust all the system-installed executable code.  If attackers can
fill a memfd with arbitrary code, it means that they already have code
execution.  This patch series will help mitigate some ways to get code
execution.

> 
> Security is very much not binary and in that vein of logic i think
> that we should probably define our shades of gray as ranges of what we
> want to protect/how and at what operational cost to then permit
> "dial-in" knobs to actually garner adoption from a broad range of
> systems outside the "real hardened efforts." At some point this turns
> into "limit users to sftp or git shells" which is a perfectly valid
> approach when the context permits that level of draconian restriction
> but the architectural breakdown of "native command, interpreted
> context, fully binary" shell types is pretty universal with new ones
> being API access into runtimes of clouds (SSM/serial/etc) which have
> their own set of limitations at execution and interface layers.
> Organizing defensive functions to handle the primitives necessary for
> each of these shell classes would likely help stratify/simplify this
> conversation and allow for more granular tasking toward those specific
> objectives.

Thanks for the discussion.  I agree, but the difficulty with this patch
series is that it brings a simple *building block*.  Of course, this
will definitely not be enough to secure any systems, but it will fill a
gap in some secure systems, and it could also harden more generic
systems (e.g. restricted system services which should not need shell
access).  I listed some examples with the new securebits proposal:
https://lore.kernel.org/all/20240710.eiKohpa4Phai@xxxxxxxxxxx/

> 
> Thanks,
> -Boris
> 
> 
> On Tue, Jul 16, 2024 at 1:48 PM Mickaël Salaün <mic@xxxxxxxxxxx> wrote:
> >
> > (adding back other people in Cc)
> >
> > On Tue, Jul 16, 2024 at 01:29:43PM -0400, Boris Lukashev wrote:
> > > Wouldn't count those shell chickens - awk alone is enough and we can
> > > use ssh and openssl clients (all in metasploit public code). As one of
> > > the people who makes novel shell types, I can assure you that this
> > > effort is only going to slow skiddies and only until the rest of us
> > > publish mitigations for this mitigation :)
> >
> > Security is not binary. :)
> >
> > Not all Linux systems are equals. Some hardened systems need this kind
> > of feature and they can get guarantees because they fully control and
> > trust their executable binaries (e.g. CLIP OS, chromeOS) or they
> > properly sandbox them.  See context in the cover letter.
> >
> > awk is a script interpreter that should be patched too, like other Linux
> > tools.
> >
> > >
> > > -Boris (RageLtMan)
> > >
> > > On July 16, 2024 12:12:49 PM EDT, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote:
> > > >On Tue, 2024-07-16 at 17:57 +0200, Roberto Sassu wrote:
> > > >> But the Clip OS 4 patch does not cover the redirection case:
> > > >>
> > > >> # ./bash < /root/test.sh
> > > >> Hello World
> > > >>
> > > >> Do you have a more recent patch for that?
> > > >
> > > >How far down the rabbit hole do you want to go?  You can't forbid a
> > > >shell from executing commands from stdin because logging in then won't
> > > >work.  It may be possible to allow from a tty backed file and not from
> > > >a file backed one, but you still have the problem of the attacker
> > > >manually typing in the script.
> > > >
> > > >The saving grace for this for shells is that they pretty much do
> > > >nothing on their own (unlike python) so you can still measure all the
> > > >executables they call out to, which provides reasonable safety.
> > > >
> > > >James
> > > >