Re: [CVE assignment notification] CVE-2012-2142 poppler, xpdf: Insufficient sanitization of escape sequences in the error message {AKA request for feedback if CVE to be marked as disputed / rejected}

[Jan Lieskovsky <jlieskov () redhat com>]

Poppler upstream patch:
  http://cgit.freedesktop.org/poppler/poppler/commit/?id=71bad47ed6a36d825b0d08992c8db56845c71e40

Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Response Team

> Hello Kurt, Steve, vendors, Mitre CVE assign department,
>
>   long time ago (in the February of 2012 yet) we have received
> the following private report from Phillips Wolf:
>
> * poppler, xpdf: Insufficient sanitization of escape sequences in the error
> messages
> -------------------------------------------------------------------------------------
>
>   An insufficient escape sequences sanitization flaw was found in the way
>   xpdf, a PDF file viewer for the X window system, and poppler, a PDF
>   rendering library, performed sanitization of certain characters to be
>   displayed in the error messages, which arose during presentation of
>   certain PDF files. A remote attacker could use this flaw to modify a
>   window's title, or, possibly execute arbitrary commands or overwrite
>   files, via a specially-crafted PDF file containing an escape sequence for
>   a terminal emulator if local, unsuspecting user opened such crafted PDF
>   file in xpdf or in an application linked against poppler library (for
>   example evince).
>
>   References: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-2142
>
> We tested, confirmed the deficiency and based on that assigned CVE-2012-2142
> identifier to the problem. Marek Kasik (Red Hat poppler package maintainer)
> has provided the following patch against (in that time) upstream poppler
> version:
>   [P] https://bugzilla.redhat.com/show_bug.cgi?id=789936#c25
>
> We also contacted poppler and xpdf upstreams with request to review that
> patch and agree on embargo date. The reply was as inlined:
>
> Albert Astals Cid (lines prefixed with '>' are my words):
> =========================================================
> "> Hi Albert,
>
> Hi
>
> >   we wouldn't have objections against sharing this patches public
> > (and opening our CVE-2012-2142 bug for public audience).
> >
> > But prior doing that can we agree on upstream classification of this
> > one? Is the intention to apply the patch still just 'preventive measure',
> > thus upstream doesn't consider CVE-2012-2142 to be a security flaw?
> >
> > Or would you admit that this is a security issue and it can be treated
> > as such?
>
> To be honest, as we discussed, I understand this is a flaw of whoever is
> receiving our output, I don't mind "sanitizing" our output for everyone's
> benefit, but as it is poppler's duty to not crash on broken/invalid/malicious
> PDF files, it is whoever is processing poppler's output to not crash or
> malfunction on broken/invalid/malicious input.
>
> Does that help in your classification?
>
> Cheers,
>   Albert
> =========================================================
>
> Derek B.Noonburg (lines prefixed with '>' are my words):
> ========================================================
> > Some examples what can be achieved by escape sequences:
> >
> > [1] http://rtfm.etla.org/xterm/ctlseq.html
> > [2] http://lwn.net/Articles/24198/
> > [3] http://en.wikipedia.org/wiki/ANSI_escape_code#CSI_codes
> > [4] http://www.termsys.demon.co.uk/vtansi.htm
> >
> > Someone might argue that this is not a xpdf's / poppler's problem (they
> > just take
> > the input from the PDF file, parse what's possible to proceed, and display
> > the
> > rest to the standard error output).
> >
> > But as noted in [2] there are numerous cases, when improper escaping of
> > escape
> > sequences could lead to malicious effects. And I assume the last thing the
> > xpdf /
> > poppler user, when viewing an untrusted / downloaded PDF file would be,
> > they would
> > need to worry about if viewing that file couldn't do something malicious on
> > their
> > host.
> >
> > Thus Marek's patch escapes all the non-printable characters, which might be
> > such
> > intentionally included escape sequences, they to be sanitized yet prior
> > they are logged
> > into standard error output.
> >
> > Hopefully the above explains our motivation behind having such patches in
> > both
> > upstream codes.
>
> Wouldn't it make more sense to treat this as a security hole in the
> terminal emulator (xterm or whatever)?
>
> If a sequence of escape characters sent to stdout/stderr can cause a
> security problem, then all an attacker would need to do would be to
> place the escape sequence in, e.g., a README file in a source code
> tarball.  Surely you wouldn't consider that to be a security hole in
> cat?
>
> The bugtraq post referenced in [2] says this:
>
> "The responsibility should rest on the actual terminal emulator; any
> features that allow file or command-line  access should be disabled by
> default and more attention should be paid to new features that
> implement any use of escape sequences."
>
> - Derek
> ========================================================
>
> While we don't agree with poppler's / xpdf's upstream opinion (apply
> the patches, but not to call the issue as a security flaw), since for example
> not
> that recent, similar problem in Apache's httpd web server's mod_rewrite
> module problem:
>   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1862
>
> has got a CVE identifier [and "security flaw treatment"], we don't
> want to argue with them longer => so if the CVE identifier should be revoked
> as disputed / invalid / rejected at the end, we will leave that decision
> to vendors / Mitre team.
>
> What matters is, the issue is there, and this post is intended as
> notification
> for vendors who might want to apply Marek's patch [P] to protect their
> instances.
>
> Thank you && Regards, Jan.
> --
> Jan iankko Lieskovsky / Red Hat Security Response Team