Bug 834475 - VUL-1: CVE-2012-2142: xpdf: Insufficient sanitization of escape sequences in the error message
VUL-1: CVE-2012-2142: xpdf: Insufficient sanitization of escape sequences in ...
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
Other Other
: P4 - Low : Minor
: ---
Assigned To: Peter Simons
Security Team bot
Depends on:
Blocks: 1133493
  Show dependency treegraph
Reported: 2013-08-12 15:50 UTC by Alexander Bergmann
Modified: 2020-09-23 15:32 UTC (History)
4 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

CVE-2012-2142 patch (1.72 KB, patch)
2019-04-26 05:59 UTC, Alexander Bergmann
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Bergmann 2013-08-12 15:50:26 UTC
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,


>   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?



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
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:

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

Thank you && Regards, Jan.


Poppler upstream patch:

Adapted Poppler's CVE-2012-2142 fix to xpdf-3.03:
Comment 1 Alexander Bergmann 2013-08-12 15:52:53 UTC
The poppler issue is tracked in bug#834476.
Comment 2 Swamp Workflow Management 2013-08-12 22:00:15 UTC
bugbot adjusting priority
Comment 5 Petr Gajdos 2013-08-26 08:33:03 UTC
(In reply to comment #4)
> > https://bugzilla.redhat.com/show_bug.cgi?id=996052#c10
> I think you mean from https://bugzilla.redhat.com/show_bug.cgi?id=789936#c29

Exactly :-).
Comment 8 Alexander Bergmann 2019-04-26 05:59:08 UTC
Created attachment 803652 [details]
CVE-2012-2142 patch
Comment 9 Wolfgang Frisch 2020-09-23 15:32:27 UTC
Currently tracked as affected in: