[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 9 Aug 2013 05:35:32 -0400 (EDT)
From: Jan Lieskovsky <jlieskov@...hat.com>
To: oss-security@...ts.openwall.com
Cc: "Steven M. Christey" <coley@...us.mitre.org>,
Marek Kasik <mkasik@...hat.com>, Albert Astals Cid <aacid@....org>,
"Derek B. Noonburg" <derekn@...labs.com>,
Mitre CVE assign department <cve-assign@...re.org>
Subject: 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}
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
>
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
