Bug 834475

Public via oss-security.

From: Jan Lieskovsky
Date: Fri, 9 Aug 2013 05:12:46 -0400 (EDT)
Subject: [oss-security] [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}

  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.


----------------------------------------
Fixes:

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

Adapted Poppler's CVE-2012-2142 fix to xpdf-3.03:
http://sourceforge.net/projects/miscellaneouspa/files/misc/xpdf-3.03-CVE-2012-2142.diff