Re: [htdig3-dev] Re: ExternalTransport and shell escaping


Subject: Re: [htdig3-dev] Re: ExternalTransport and shell escaping
From: Gilles Detillieux (grdetil@scrc.umanitoba.ca)
Date: Mon Feb 14 2000 - 14:15:11 PST


According to Geoff Hutchison:
> On Mon, 14 Feb 2000, Gilles Detillieux wrote:
> > > Evidently, we'd need to escape shell meta-characters because they have
> > > higher priority than the quotes.
> >
> > No, that's not right. Either Jonathan is mistaken, or he has a buggy shell
> > or popen() on his system. An ampersand inside double quotes is NOT supposed
> > to be interpreted by the shell! It would be a good idea to backslash-escape
> > certain meta characters that do have special meaning within double quotes,
> > but these are limited to `, $, !, and of course " itself.
>
> That's what I thought too, but since I'm an experimentalist, I tried this
> from my bash prompt:
>
> handler.pl https "https://bal.com&rm" /etc/htdig/htdig.conf
>
> I was fairly sure that the ampersand was NOT supposed to be interpreted,
> but in any case, I didn't have the privs to remove htdig.conf. I got an
> error message back from rm. Try it! It might be a bug in bash, but it's a
> bit irrelevant--we have to work around it.
>
> > arguments from his script to other programs. Or maybe there's a bug on
> > his system. I had tested the external parser quoting fix on my system,
> > and it worked.
>
> I dunno. Try the test above from your bash prompt and let me know. I'd say
> if *I* can do it reproducibly, then there's some version of bash with this
> bug and we need to worry about it from a security standpoint.

I got this... :-)

bash: handler.pl: command not found

Have you had a look at the contrib/handler.pl script? It quite obviously
passes an unquoted URL to the curl command, in the open() statement, which
I assume is parsed by the shell (or Perl applies shell-like parsing to it).
When I ran the script with the same arguments, I got the errors:

sh: /usr/local/bin/curl: No such file or directory
rm: too few arguments
Try `rm --help' for more information.

The first is because I don't have curl installed on my system. The error
message from rm is because there were no arguments at all given to rm.
It still didn't try to remove the configuration file, because the name
of it doesn't appear on the command line for curl.

So:
- ExternalParser.cc and ExternalTransport.cc should probably be fixed
  to backslash-escape at least the double quote character, and probably
  also `, $, and ! in URLs. That won't solve this problem, but it's a
  good precaution.
- contrib/handler.pl should probably do likewise to the URL, before
  passing it to curl, but as a bare minimum it MUST quote the URL.
- If Jonathan was indeed having a problem with his external protocol
  handler actually removing the htdig.conf, then his problem is still
  different than what I've been shown or been able to reproduce. He's
  either using a different script, or there's a bug somewhere on his
  system. It's hard to say from his one brief message on the subject,
  because he never mentioned what script he was using, what it was doing
  with its arguments, or even what error messages he got.
- Passing the URL to the script via stdin will not help, if the script
  that receives it turns around and passes the URL to another shell
  command as an unquoted argument.

-- 
Gilles R. Detillieux              E-mail: <grdetil@scrc.umanitoba.ca>
Spinal Cord Research Centre       WWW:    http://www.scrc.umanitoba.ca/~grdetil
Dept. Physiology, U. of Manitoba  Phone:  (204)789-3766
Winnipeg, MB  R3E 3J7  (Canada)   Fax:    (204)789-3930

------------------------------------ To unsubscribe from the htdig3-dev mailing list, send a message to htdig3-dev-unsubscribe@htdig.org You will receive a message to confirm this.



This archive was generated by hypermail 2b28 : Mon Feb 14 2000 - 14:18:06 PST