Unauthenticated flag flipping yields remote code execution
rachelbythebay.com
Unauthenticated flag flipping yields remote code execution
1–10 of 21 posts
Re: Unauthenticated flag flipping yields remote code execution
#2In short, ambient authority strikes again. Environment variables were a terrible design mistake in UNIX.
Re: Unauthenticated flag flipping yields remote code execution
#3I'm categorically against shelling out for anything from a web based service. If you need this sort of functionality implement a queue, send a signal using some IPC process and wait until the job is done.
Exec'ing anything (even Postscript, which is after all a full fledged programming language) is a huge risk. Ensure that the input you receive is not malicious and if you can recompile any executables that will process hostile inputs to process only the subset of commands and functions that you think should be able to deal with untrusted input.
And of course you still have to properly sandbox those programs.
Re: Unauthenticated flag flipping yields remote code execution
#4In short, ambient authority strikes again. Environment variables were a terrible design mistake in UNIX.
If env vars didn't exist, the people who do the awful things described in TFA would still do those awful things. In fact the problems described there mostly took place when env vars were overridden by command line flags and unauthenticated web server requests.
Re: Unauthenticated flag flipping yields remote code execution
#5In short, ambient authority strikes again. Environment variables were a terrible design mistake in UNIX.
Environment variables are not the problem. It's environment variables with too much power and the possibility to change them remotely.
Re: Unauthenticated flag flipping yields remote code execution
#6I'm categorically against shelling out for anything from a web based service. If you need this sort of functionality implement a queue, send a signal using some IPC process and wait until the job is done. Exec'ing anything (even Postscript, which is after all a full fledged programming language) is a huge risk. Ensure that the input you receive is not malicious and if you can recompile any executables that will proce…
Two other important points:
1. Those command line programs weren't necessarily designed with an adversarial user in mind! Sanitizing input to prevent shell escape sequences is not enough. You really need to sandbox well.
2. For some tasks, it might be easy for a malicious user to guess which command-line tool you are using. You might be getting way less depth out of obscurity than you think you are.
Re: Unauthenticated flag flipping yields remote code execution
#7Dang. Would containerization solve this, or at least help mitigate the damage?
Rachel's stories are always interesting, I always find myself learning new things from them, and I have been for over a decade now. They are a great reminder of my sysadmin past, now that I mostly do DBA work anymore. However, I do wonder if I should be sending her aspirin or tequila as tribute at times...
Re: Unauthenticated flag flipping yields remote code execution
#8In short, ambient authority strikes again. Environment variables were a terrible design mistake in UNIX.
Very vague post. Next time please write specific examples. Everyone should sanitize inputs.
Re: Unauthenticated flag flipping yields remote code execution
#9In short, ambient authority strikes again. Environment variables were a terrible design mistake in UNIX.
Very vague post. Next time please write specific examples. Everyone should sanitize inputs.
> Everyone should sanitize inputs.
"Sanitize your inputs!" is the security equivalent of abstinence-only sex education. Yes, it technically will fix the problem if executed perfectly, but an endless history of failure should have convinced everyone by now that it is not the right solution for the real world. As other commenters have pointed out, shells were never designed with adversarial input in mind and so "sanitizing" them means hunting down and endless number of bugs and still not knowing if you've done it correctly.
The correct way is to design from the start so that user input cannot be executed. For SQL, everyone now knows that means parametrized statements; in this case, it means job queues and standalone processes with locked-down privileges.
Re: Unauthenticated flag flipping yields remote code execution
#10I'm categorically against shelling out for anything from a web based service. If you need this sort of functionality implement a queue, send a signal using some IPC process and wait until the job is done. Exec'ing anything (even Postscript, which is after all a full fledged programming language) is a huge risk. Ensure that the input you receive is not malicious and if you can recompile any executables that will proce…
> Ensure that the input you receive is not malicious
To do that input needs to be decidable. Input from possibly-malicious sources needs to be limited to a grammar no more complex than deterministic context-free[1]. Accepting Turing complete input introduces the possibility that recognizing anything about the input might be provably undecidable.