Bug 834475

Summary: VUL-1: CVE-2012-2142: xpdf: Insufficient sanitization of escape sequences in the error message
Product: [Novell Products] SUSE Security Incidents Reporter: Alexander Bergmann <abergmann>
Component: IncidentsAssignee: Peter Simons <peter.simons>
Status: CONFIRMED --- QA Contact: Security Team bot <security-team>
Severity: Minor    
Priority: P4 - Low CC: abergmann, krahmer, mancha1, wolfgang.frisch
Version: unspecified   
Target Milestone: ---   
Hardware: Other   
OS: Other   
URL: https://smash.suse.de/issue/75044/
Whiteboard: CVSSv2:RedHat:CVE-2012-2142:2.6:(AV:N/AC:H/Au:N/C:N/I:P/A:N) maint:planned:update CVSSv3.1:NVD:CVE-2012-2142:7.8:(AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H)
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Bug Depends on:    
Bug Blocks: 1133493    
Attachments: CVE-2012-2142 patch

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: