Home page logo
/

oss-sec logo oss-sec mailing list archives

[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}
From: Jan Lieskovsky <jlieskov () redhat com>
Date: Fri, 9 Aug 2013 05:12:46 -0400 (EDT)

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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault