I would have loved some concrete examples.
Unauthenticated flag flipping yields remote code execution
11–20 of 21 posts
Re: Unauthenticated flag flipping yields remote code execution
#12I'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. [1] https://archive.org/details/The_Science_of_Insecurity_
There is another mathematically-correct layer of security you can get, though, which is the IO interface to the real world that you provide the input. Barring (huge!) bugs in the (very simple!) interpreter, it doesn't matter how much basic brainfuck [1] from a user you execute, they aren't going to get a shell. Worst they can do is burn CPU until you shut them down. (Brainfuck interpreters are already generally pretty tightly RAM limited.)
Sandboxing is of course easier said than done, but it's still mathematically valid. The problem is that our real hardware has too many metaphorical sharp edges from a mathematical point of view, not that it doesn't work.
Re: Unauthenticated flag flipping yields remote code execution
#13In short, ambient authority strikes again. Environment variables were a terrible design mistake in UNIX.
Being old enough to remember the special hell that was CGI, that particular mechanism showing up in 12 Factor Apps doesn't sit entirely well with me.
It doesn't stop me from supporting it as a deployment process, but there's a 22 year old inside of me that cries a little every time I talk about using environment variables for config.
Re: Unauthenticated flag flipping yields remote code execution
#14In 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.
Yes except now I have 40 microservices that I have to make sure all parse URL parameters properly instead of the one I used to have that would parse them and then put them where everyone else could find it.
Security in depth is hamstrung by an ever-increasing surface area.
Re: Unauthenticated flag flipping yields remote code execution
#15Earlier quoted context omitted.
Very vague post. Next time please write specific examples. Everyone should sanitize inputs.
Yes except now I have 40 microservices that I have to make sure all parse URL parameters properly instead of the one I used to have that would parse them and then put them where everyone else could find it. Security in depth is hamstrung by an ever-increasing surface area.
I'd say that if your microservices aren't sharing that type of code, you've probably made a software design mistake. Perhaps beside the point, but that's a bit of a contrived example.
I mean, people doing things wrong isn't evidence that they cannot be done right... right?
Re: Unauthenticated flag flipping yields remote code execution
#16Earlier quoted context omitted.
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 "saniti…
Ehh... how many instances of unsanitized input leading to RCE were due to the subtleties of the interpreter, and how many are the result of people blithely passing user input into the interpreter, not using the sanitation functions available in most mainstream languages (in many cases, in the standard library)?
If getting people to do this is impossible, so is getting people to stop storing passwords in plaintext.
Re: Unauthenticated flag flipping yields remote code execution
#17Earlier quoted context omitted.
> 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 "saniti…
Ehh... how many instances of unsanitized input leading to RCE were due to the subtleties of the interpreter, and how many are the result of people blithely passing user input into the interpreter, not using the sanitation functions available in most mainstream languages (in many cases, in the standard library)? If getting people to do this is impossible, so is getting people to stop storing passwords in plaintext.
> If getting people to do this is impossible, so is getting people to stop storing passwords in plaintext.
This may very well be the case, though. You may get most people to know that storing passwords in plaintext is not a great idea (tm), but there will always be people ignoring that, be it due to downright ignorance or external factors.
I can envision some non-technical person in an organisation prescribing to IT that a new user password cannot look like one of the user's old passwords, where "look like" actually means something like an edit distance of <=2. Since the secure way of implementing this is looping over all possible passwords close to the one the user entered now, hashing them all and comparing them to a list of past hashes (which is quite resource-intensive, which costs mony), I bet there will be people that will give in and just store the last few passwords in plaintext. Maybe they'll encrypt them, but they'll be there.
Re: Unauthenticated flag flipping yields remote code execution
#18Dang. 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...
You could probably limit some of the insanity by walling off things that you absolutely need to run and can't work around. Even then you still have to worry about someone having too much fun inside the jail, container, or whatever your system offers.
As for aspirin and friends, well, being effectively retired has done wonders of late. But thanks!
Re: Unauthenticated flag flipping yields remote code execution
#19In 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.
I can give you an example of somethign that is relatively common and "bad".
Imagine a website that will take an URL and extract the text from it - removing markup - or another service that will scan a URL for meta-tags, etc. All the kind of things that you can find easily.
Now imagine what happens if a user passes input such as "file:////etc/passwd". There are a whole bunch of services which will spit out the contents of the file, because they use some URL-fetching library and don't limit the protocols to http or https.
I wrote a blog-post about that, which was featured here a while back:
Re: Unauthenticated flag flipping yields remote code execution
#20I'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.
That's one very important reason why you want that queue. That way you at least break the most obvious path to return output.