Re:Writing a full-text search engine using Bloom filters (2013)
by kragen on Wednesday June 10, 2020 @03:17AM
(#23474763)
This is a good point. Even if you don't have a shell injection vulnerability, you may end up with a path traversal vulnerability. In this particular case I think you're probably pretty safe as long as you're careful to only pass a single argument to the grep process — but it depends on how exactly grep parses its arguments. If there's a way to sneak ../ in there, you might get hurt.
Bleh. I can see why people install WAFs.
Re:Writing a full-text search engine using Bloom filters (2013)
by stavros on Wednesday June 10, 2020 @07:25AM
(#23475894)
I've lately become allergic to things that I can only partially reason about. Sure, I'm probably going to be fine, but I can't guarantee I'll be fine, and the blackhats are always more knowledgeable than me about obscure bits of shell/Unix behavior, so I just shy away and use a less free-form approach.
I've actually reported a couple of security bugs in servers in the past, which were caused by people running grep for searches.
Imagine you have a tree of web-content at /var/www, when a user searches for "foo" you run "grep -r -h foo /var/www", then you parse out the resulting filenames.
Now imagine what happens if your user searches for "foo /tmp; rm -rf /". Whenever you pass user-input to a command-line application you need to be damn sure you know what you're doing - if the shell is involved in parsing your command you'll have problems.