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. 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. 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. 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. 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, -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 > > >
