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.
