What is your opinion on this guys? Basically the problem seems to be we can "print" in the error messages characters that will result in command codes that will result in shell terminals executing code.
I've already told the redhat people i consider this to be a shel terminal problem not a poppler one, but it doesn't mean we could try to "be good citizens" and help. Any opinion on the proposed patch for upstream? Cheers, Albert
--- Begin Message ---Hello Albert, thank you for the follow-up on this one. See the attached archive poppler-CVE-2012-2142-proposed-patches-by-Marek-Kasik.tar.bz2 (contains proposed patches for all of: 1) Red Hat Enterprise Linux 5, 2) Red Hat Enterprise Linux 6, 3) Fedora-17, 4) popler upstream version) as created by Marek Kasik on 2012-04-26 09:31:19 EDT (=> not sure if the upstream proposed one would be still working without further changes). Internal comment from Marek is also inlined: <comment> As I wrote before, we need to perform the sanitization also at all other error functions. This apply to rhel6 and all fedoras. rhel5's poppler doesn't set another error function elsewhere. rhel6's poppler sets it for qt4 backend. fedoras set it for qt4 and cpp backend. Current upstream doesn't need to patch all the error functions, just the default one since it passes its resulting string to those functions. Attached are patches for rhel5, rhel6, f17 and upstream. Marek </comment> Please have a look && let us know your opinion. Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Response Team ----- Original Message ----- Wops, i see i failed to answer this in May :-S You mention some patches available, can I see them? Cheers, Albert El Dimecres, 2 de maig de 2012, a les 19:20:36, Jan Lieskovsky va escriure: > On 04/27/2012 11:45 PM, Albert Astals Cid wrote: > > El Divendres, 27 d'abril de 2012, a les 11:34:23, Derek B. Noonburg va > > > > escriure: > >> On 2012 Apr 27, Jan Lieskovsky wrote: > >>> Hello Albert, > >>> > >>> thank you for your reply. > >>> > >>> On 04/27/2012 03:55 PM, Albert Astals Cid wrote: > >>>> --- El vie, 27/4/12, Jan Lieskovsky escribió: > >>>>> Hello Derek, Albert, > >>>> > >>>> Hi > >>>> > >>>>> the following security flaw has been reported > >>>>> > >>>>> privately by Phillips Wolf to us: > >>>>> > >>>>> 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). > >>>>> > >>>>> Attached is the patch by Marek Kasik (Red Hat poppler > >>>>> package maintainer), as > >>>>> intended to be applied against upstream poppler code. > >>>> > >>>> I fail to see how a fprintf to stderr can be exploited. Can you please > >>>> explain it to me?> > >>> > >>> The issue is that xpdf / poppler / evince tries to parse the provided > >>> PDF > >>> file and when encountering an error they print the non-printable > >>> characters without escaping to the standard error log (terminal or file > >>> when redirected). > >>> > >>> Thus someone knowing this behaviour could send you a intentionally wrong > >>> / > >>> damaged PDF file just to cause terminal sequences to be executed > >>> (depending on the terminal emulator you are using and if it honours > >>> escape sequences): > >>> > >>> 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. > > Hello Albert, Derek, > > >> 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." > > Historically it seems to be the responsibility of both underlying pieces > to correct the behaviour: > [1] http://www.gossamer-threads.com/lists/openssh/users/46550 > (openssh /etc/banner | /etc/issue case) > [2] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1488 > (wget case) > [3] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0083 > (Apache's httpd case) > [4] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0020 > (another Apache one) > [5] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2713 > (vte case) > > As you can see, those non-terminal fixes based one are pretty old > (as a progress has been done / fixes has been applied in recent > terminal emulators code, to prevent occurrence of these flaws). > > Honestly, it's not that easy to make for example Gnome terminal > to change the window's title. > > As noted in: > [6] http://ubuntuforums.org/archive/index.php/t-448614.html > > the recent working way, how to do it being as follows: > > $ unset PROMPT_COMMAND; echo -ne "\033]2;NewWindowTitle\007" > > In any case, the fact the xpdf / poppler (evince) beeps on > (pre)viewing those PDF files is a note of the fact, that > it might still be possible to cause malicious things even > on recent terminal emulators (which have been patched against > escape sequences vulnerabilities). > > > I'm with Derek here, as far as i undertand each terminal emulator has > > different escape sequences, you could even be running where outputting b > > to > > the command line means you'll send a nuke to someone, basically we are > > "santizing" for the unknown, in my opinion it is the terminal that should > > sanitize its input (fix it in one place) and not the porgrams that write > > to > > the shell (fix it in lots of places?) > > Due what to sanitize (too many different escape sequences) -- wouldn't help > if we would follow the openssh's approach (from [1]): > > <quote> > After doing some more digging, I found that there is a function in the ssh > source (specifically sshconnect2.c) called "input_userauth_banner" that > displays the banner from the server. The text of the banner is now being > filtered through another function called "strnvis" that encodes > non-printable ascii characters as printable text, ie: octal codes. This is > why the ansi escape sequence is displayed as "\033[.". The documentation > for strnvis doesn't mention any security issues, only "unexpected behavior" > that could be associated with non-printable characters. > > The only mention of this change to the ssh code is this rather terse entry > in the changelog: > > - djm [at] cvs 2008/07/17 08:48:00 > [sshconnect2.c] > strnvis preauth banner; pointed out by mpf@ ok markus@ > > </quote> > > Basically Marek's patch is proposing is the same (encode non-printable > ascii characters as printable text - octal codes). > > Upon more detailed search more examples of applications / open-source > code projects could be found which have patched this kind of issues > in the past (the above list being result of just quick five minutes > search). > > Albert, Derek, in the light of the above, would you consider inclusion > of relevant patches into upstream xpdf and poppler codes? > > Thanks for your time && Regards, Jan. > -- > Jan iankko Lieskovsky / Red Hat Security Response Team > > > Cheers, > > > > Albert > >> > >> - Derek
poppler-CVE-2012-2142-proposed-patches-by-Marek-Kasik.tar.bz2
Description: application/bzip-compressed-tar
--- End Message ---
_______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
