-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Hackers Ok, so I’ve been a bit quiet recently, what with college and exams. But the semesters nearly over now so I’ll have plenty of time to keep you all up to date with what those fools at CERT are up to once college is finished. Anyway, on with the show, here we have a nice little hole allowing you to execute shell commands by embedding them in PDF files. Obviously no one’s likely to be reading PDF’s as root on a production server, but nice for rm’ing those ankle biting Linux lusers. You’ll also some example code. There was also some example code for mapping untrusted URIs to a safer format, but I’m not releasing that, we’re here to *HACK* boxes not to Patch them! You’ll also notice that this takes the format of the form used to report holes to CERT rather than my usual draft advisory format. If you want to wait for the actual CERT advisory (probably with out details of how to exploit it) they will be releasing it on Monday 23rd June 2003, making my release –10 Day! Hack4Life #####NOT FOR PUBLIC DISTRIBUTION##### CONTACT INFORMATION Let us know who you are: Name: Martyn Gilmore E-mail: gilmoreat_private Phone / fax: 513-374-1586 Affiliation and address: 1068 Archland Drive, Cincinnati, OH 45224 Have you reported this to the vendor? [yes/no] no Please describe the vulnerability. Valid PDF files can contain malicious external-type hyperlinks that can execute arbitrary shell commands underneath Unix with various PDF viewers/readers. The hyperlinks must be activated or followed for the malicious script to run. The obvious case is for a user to click on one. The PDF viewers/readers, which are known to be vulnerable at this time, appear to spawn (exec) the associated external program handlers with "sh -c". "sh -c <registered-program> <embedded-hyperlink>" What is the impact of this vulnerability? - - - ---------------------------------------- (For example: local user can gain root/privileged access, intruders can create root-owned files, denial of service attack, etc.) a) What is the specific impact: Under probable conditions, arbitrary Unix shell commands can be executed with the PDF reader/viewer user's privileges when malicious hyperlinks are activated. b) How would you envision it being used in an attack scenario: Many are possible (especially if the user has more privileges). I don't know, if there are any real restrictions on the embedded shell script's length. To your knowledge is the vulnerability currently being exploited? - - - ---------------------------------------------------------------- [yes/no] no If there is an exploitation script available, please include it here. - - - ----------------------------------------------------------------- - --- Attachment evil.pdf contains the embedded command `rm -rf $HOME/monkey` Preconditions: 1. User's home directory does NOT contain a file or directory named 'monkey' 2. Run 'touch $HOME/monkey' 3. Adobe Acrobat 5.06 on Redhat 8.0 only performs the "sh -c" type of action when there is no current running browser/email program (i.e. mozilla). Exploit: Open PDF file and click on gilmoreat_private hyperlink Proof of exploit: Absence of $HOME/monkey With the help of pdflatex, the attachment evil.tex is the source document for evil.pdf. Other "flexible" PDF authoring solutions probably would work too. Do you know what systems and/or configurations are vulnerable? - - - ------------------------------------------------------------- [yes/no] (If yes, please list them below) System : PDF viewers/readers, which spawn external programs with "sh -c" to handle certain types of hyperlinks. OS version : Most Unix versions Verified/Guessed: Guessed (beyond what I report below) I've only verified the following programs on Redhat Linux 8.0. Xpdf 1.01 Adobe Acrobat Reader 5.06 Xpdf executes the malicious embedded script, regardless of whether the handler is currently running or not. The Ghostview derivative on my machine, doesn't have hyperlinks enabled (ignores that aspect of the PDF file). Others readers maybe affected as well. Are you aware of any workarounds and/or fixes for this vulnerability? - - - ----------------------------------------------------------------- - --- [yes/no] (If you have a workaround or are aware of patches please include the information here.) I'm aware of no fixes in any PDF readers/viewers. Each program's implementation may differ (languages, dynamic memory libraries) to prevent a universal fix, however suggested guidelines are given below. These guidelines are an attempt to offer a robust solution with a minimal effect on existing behavior. If the "sh -c" type of invocation is a necessary way to spawn external browser/email program(s), then the embedded hyperlink should be properly quoted/escaped. The "sh -c" type of invocation maybe desirable to allow, the configuration of the external programs to contain environmental variables. i.e. "sh -c $USER_BROWSER args" The easiest solution (IMHO) underneath these types of scenarios is to enclose the embedded hyperlink within single quotes (avoids escaping the entire Unix shell meta-character soup). In addition, any single quotes found within the original embedded hyperlink, should be replaced with '"'"' (i.e. "\'\"\'\"\'" for C/C++ programs). Programs will have to deal correctly with possibilities of unknown-length string expansion or risk overwrites of the heap or stack; use of std::string or RWCString in C++ would simplify the design, if they are available. Testing will require conditions to trigger the "sh -c" type of invocation (i.e. browser/email program not running) for each PDF reader/viewer. 1.) Hyperlinks with embedded shell exploits will not be executed. 2.) Proper email addresses such as "Martyn%20Gilmore<gilmoreat_private>" and "gilmoreat_private(Martyn%20Gilmore)" should now work as "mailto:" targets. These legitimate uses are how the exploit was discovered, since some Unix shell meta-characters are present and prevent positive functionality from occurring. Caveats/Notes: The solution above is a result of correcting the direct actions of the PDF viewer/reader against misuse. The user configurable spawned programs are trusted to not eval their arguments further, otherwise the original exploit returns. The potential security breach of additional evals is the onus of the configured handler or the end-user (not having a secured environment or not having an responsible entrusted handler). Clarification of initial report: Besides the potential for explicit "sh -c" in an exec*() Unix system calls, the C StdLib system() call performs one implicitly. Better Proposed Fix: I think that my first proposed fixed was too naive.? Mozilla 1.3 has a shell wrapper that calls eval.? Other configured browers/handlers could have the same problem or could easily introduce one, even if unintentional (check-in of a developer copy). Granted the programs I originally cited as guilty parties execute the malicious code first, however they are only the first in a potential chain. Rather than trying to correct the whole round trip (more programs), it is more feasible for PDF viewer/reader party to make sure their "Untrusted URIs" don't have immediate or long-term potential for problems.? The effort is about the same as the original suggestion. I've attached a small example C++ program that maps untrusted URIs to a safer format, which is a far better alternative to the Unix-based quoting that only lasts one round and has potential to pass the buck. -----BEGIN PGP SIGNATURE----- Note: This signature can be verified at https://www.hushtools.com/verify Version: Hush 2.3 Charset: UTF8 wkYEARECAAYFAj7qQNQACgkQgSjHzuae7+okUQCfWQfknodvOKkIMHWuxEtei0QgTfEA njzg8owJH9nYZ1KTKun+/eey3Wgn =1m0Y -----END PGP SIGNATURE-----
This archive was generated by hypermail 2b30 : Fri Jun 13 2003 - 18:26:49 PDT