[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Avoiding command hijacking in shells (was Re: setting path for root after "sudo su" and "sudo" for Debian Bullseye (11))



On Fri, May 20, 2022 at 09:36:40PM -0400, The Wanderer wrote:
> I wasn't even thinking of it in those terms, although now that you point
> it out that's a good thing to be aware of. I was thinking of it in terms
> of A: trying to write scripts that are safe against such problematic
> elements being in the environment,

You can't.  It's really that simple -- if someone can compromise the
execution environment of your script, they can make your script do
anything they like.

Don't think that compiled programs are safe, either -- unless they're
statically linked, someone with control over the execution environment
can use LD_PRELOAD or similar environment variables to override any
library function the program calls.

With that in mind, what you do as a programmer is simply ignore the
possibility.  Your program should assume it's being run in a sane, or
at least non-malicious, environment.

At the programming level, your security responsibilities are things like:

* Use correct and safe programming practices for whatever language(s)
  you're writing in.

* Sanity-check all user inputs, whether from files, from the environment,
  or from a terminal, before you use them.

* Avoid writing programs that write programs whenever possible.  If you
  can't avoid them (e.g. if you *must* call awk from your bash script),
  be on the lookout for code injections.

> and B: being able to detect and
> recover from some piece of malware having inserted such elements into
> the environment on your *own* computer.

Many people will tell you that if your computer has been compromised,
there's no recovering from it.  It's best to wipe the file systems and
reinstall, then restore data from the last non-compromised backup.

A post-mortem analysis is possible, if you remove the hard drive(s) and
use them as non-booting data disks in another system.  From a trusted
environment like that, you can mount the file systems and inspect them
to see what has been compromised.  But it'll be tedious and time-consuming.


Reply to: