xpdf vulnerability - CAN-2003-0434

From: Andries.Brouwerat_private
Date: Wed Jul 09 2003 - 09:54:28 PDT

  • Next message: Stephen Samuel: "Re: Generic way to exploit an insecure /tmp file creation - Red Hat 7,8,9 (Re: Red Hat 9: free tickets)"

    [I sent this letter on 2003-06-28, but no letters arrived that day,
    it seems. A second attempt.]
    
    I see RedHat and Mandrake reactions to the vulnerability
    in xpdf reported by Martyn Gilmore. But their updates do
    not fix the problem.
    
    They change xpdf, and make it filter out backquotes before
    invoking urlCommand. I think that was unnecessary.
    
    On the other hand, urlCommand must be very careful what it
    does with the URL since it was remote-user-supplied.
    A urlCommand like the default "netscape -remote 'openURL(%s)'"
    is OK since the %s is protected by single quotes.
    
    A urlCommand like the RedHat "/usr/bin/xpdf-handle-url %s"
    is bad since %s is not protected and funny games are possible.
    In other words, not xpdf but /etc/xpdfrc must be fixed.
    
    Next, RedHat /usr/bin/xpdf-handle-url is bad as well, since
    it does
      xterm -e sh -c "echo Edit $0 to include your URL handler; echo $1; read"
    exposing the unquoted URL to sh -c.
    
    For example, on a RedHat 8.0 system that I have here, clicking the URL
    like "nailto:me; rm /tmp/abc" will remove the indicated file, also
    after the fix is applied.
    
    A testexample for playing with pdflatex:
    
    \documentclass[11pt]{minimal}
    \usepackage{color}
    \usepackage[urlcolor=blue,colorlinks=true,pdfpagemode=none]{hyperref}
    \begin{document}
    \href{prot:hyperlink with stuff, say, `rm -rf /tmp/abc`; touch /tmp/pqr}{\textt\
    t{Click me}}
    \end{document}
    
    All shell metacharacters are dangerous. Not only backquote.
    
    Andries
    



    This archive was generated by hypermail 2b30 : Wed Jul 09 2003 - 12:45:03 PDT