Bugzilla – Bug 95350
VUL-0: CVE-2005-1625: acrobat reader remote buffer overflow
Last modified: 2021-11-04 16:22:09 UTC
Hello, this one was published on bugtraq mailinglist. Subject: iDEFENSE Security Advisory 07.05.05: Adobe Acrobat Reader UnixAppOpenFilePerform() Buffer Overflow Vulnerability Date: Tue, 5 Jul 2005 16:25:08 -0400 Thread-Topic: iDEFENSE Security Advisory 07.05.05: Adobe Acrobat Reader UnixAppOpenFilePerform() Buffer Overflow Vulnerability Thread-Index: AcWBn7wa7zZ13InCTf+Bd9iJK20x6A== From: iDEFENSE Labs <labs-no-reply@idefense.com> To: bugtraq@securityfocus.com, vulnwatch@vulnwatch.org, full-disclosure@lists.grok.org.uk Envelope-To: tom@electric-sheep.org Adobe Acrobat Reader UnixAppOpenFilePerform() Buffer Overflow Vulnerability iDEFENSE Security Advisory 07.05.05 www.idefense.com/application/poi/display?id=279&type=vulnerabilities July 05, 2005 I. BACKGROUND Adobe Acrobat Reader is a program for viewing Portable Document Format (PDF) documents. More information is available at the following site: http://www.adobe.com/products/acrobat/readermain.html II. DESCRIPTION Remote exploitation of a buffer overflow in Adobe Acrobat Reader for Unix could allow an attacker to execute arbitrary code. The vulnerability specifically exists in the function UnixAppOpenFilePerform(). This routine is called by Acrobat Reader while The vulnerability specifically exists in the function UnixAppOpenFilePerform(). This routine is called by Acrobat Reader while opening a document containing a /Filespec tag. Within this routine, sprintf is used to copy user-supplied data into a fixed-sized stack buffer. This leads to a stack based overflow and the execution of arbitrary code. The following demonstrates what the overflow looks like in a debugger: #0 0x41414141 in ?? () (gdb) i r ebx ebx 0xbfffef54 -1073746092 (gdb) x/x 0xbfffef54 0xbfffef54: 0x40404040 (gdb) As shown, EIP is easily controllable; ebx also points to the 4 bytes before the EIP overwrite in a controlled buffer. This allows remote exploitation without having to know stack addresses, as an attacker can craft an exploit to return to a jmp ebx or call ebx instruction. III. ANALYSIS Successful exploitation allows an attacker to execute arbitrary code under the privileges of the local user. Remote exploitation is possible via e-mail attachment or link to the maliciously crafted PDF document. The impact of this vulnerability is lessened by the fact that two error messages appear before exploitation is successful; however, closing these windows does not prevent exploitation from occurring. IV. DETECTION iDEFENSE has confirmed the existence of this vulnerability in Adobe Acrobat Reader version 5.0.9 for Unix and Adobe Acrobat Reader version 5.0.10 for Unix. Adobe Acrobat for Windows is not affected. Adobe Acrobat 7.0 for Unix is not affected. V. WORKAROUND User awareness is the best defense against this class of attack. Users should be aware of the existence of such attacks and proceed with caution when following links from suspicious or unsolicited e-mail. Users should consider using an unaffected version of Adobe Acrobat, such as Acrobat 7.0 VI. VENDOR RESPONSE Adobe has addressed this issue in the following security advisory: http://www.adobe.com/support/techdocs/329083.html Adobe is recommending the following steps for remediation: -- If you use Adobe Reader 5.0.9 or 5.0.10 on Linux or Solaris, download Adobe Reader 7.0 at www.adobe.com/products/acrobat/readstep2.html. -- If you use Adobe Reader 5.0.9 or 5.0.10 on IBM-AIX or HP-UX, download Adobe Reader 5.0.11 at www.adobe.com/products/acrobat/readstep2.html. VII. CVE INFORMATION The Common Vulnerabilities and Exposures (CVE) project has assigned the name CAN-2005-1625 to this issue. This is a candidate for inclusion in the CVE list (http://cve.mitre.org), which standardizes names for security problems. VIII. DISCLOSURE TIMELINE 05/12/2005 Initial vendor notification 05/12/2005 Initial vendor response 07/05/2005 Public disclosure IX. CREDIT iDEFENSE Labs is credited with this discovery. Get paid for vulnerability research http://www.idefense.com/poi/teams/vcp.jsp Free tools, research and upcoming events http://labs.idefense.com X. LEGAL NOTICES
Must fix ASAP, looks easily remote exploitable. AJ, this is going to bite us severly, because we still have acroread5 in 9.2 and before. NLD fix can wait until SP2 (which goes out this week, right)?
This means we can only do a version update to version 7, right? In that case a version upgrade is approved where it's possible to do so without major problems. for older distros we might need to advice folks to remove acroread. So, let's try to get a version update out for at least 9.1 and 9.2 - and talk with Gerald and Thorsten about SLES9.
SM-Tracker-1744
I'm afraid we have little alternatives than doing the same for SLES9, though I wonder why we have a package like acroread, which only runs on two of our platforms, on SLES at all. Thorsten, what do you think (both on the security update and dropping this for SLES10)?
Security update: We have no choice. Dropping it: There is no free implementation is works as good as acroread itself for me.
We need updated packages ASAP ... George, are you there?
Am I supposed to check out the 9.1 and 9.2 acroread versions, update the spec file to now use the 7.0 code, or can I just checkin the 9.3 version into those previous versions? I'll start on the first option because that is how I believe I'm supposed to do it...
start with the distros that have version 7 first (stable, 9.3 , nld-sp2) 9.1 , sles9 and nld will share the same codebase for acroread at the end I hope, so we will use an RPM based on the NLD-SP2 version you already have. for 9.2, use the 9.3 version if possible.
I don't have most of these distributions to test on, however I did test the sles9 version and it worked great. I tried to build the 9.3 version building against 9.2 but it fails because of some other package that is needed for delivering the acroread.png icon. I took the current NLD one I've been working on (which installs the acroread.png also), built it succesfully on 9.1, 9.2, 9.3, and sles9. I submitted it to 9.1-beta, 9.2-beta, NLD-beta, sles9-beta, and STABLE. If I've done anything wrong let me know (I am concerned that the change log will be totally different with this package, then what they had in the v5, but maybe that is OK...) I won't be in town tomorrow until Sunday, so after that I can work on it some more if needed.
The 9.3 submission was missing. I submitted the 9.2 one to 9.3 too. Btw, does adobe supply us the non-versioned tarball this way? this is a bit irritating.
this leaves vulnerable: ul1-i386 , sles8-slec-i386 8.2-i386 and 9.0-i386 Ralf, Gerald, Andreas ... what to do?
patchinfos submitted for 9.1-9.3 and sles9 / Nld
8.2 is at the end of it's lifetime. If we can do the same for 9.0 as for 9.1 fine - otherwise announce that no fix is available.
Marcus, according to comment #5 by Thorsten and comment #4 we don't have a choice, so we'll need to update ul1-i386 and sles8-slec-i386 as well, don't we?
rpm -q --requires -p /work/CDs/all/full-9.1-i386/suse/i586/acroread.rpm |grep GLIBC ... libc.so.6(GLIBC_2.3) tough luck, since sles8 is GLIBC 2.2.5 based. any further insights?
The maintenance update (f8ccd543430abb4644c845b0ed77b60f, YOU-Patchfile: 10304) does not work on nld9-x86_64: brecht:~ # /usr/X11R6/bin/acroread Aborted A stack trace will be attached.
Created attachment 41631 [details] stack trace of acroread7 on nld-x86_64
After installing glibc-locale-32bit from GA, acroread does work. Looks like a dependency problem. rpm -Va --nofiles did not complain after applying the patch without having glibc-locale-32bit installed !
On our reference host for sles9-x86_64, I see another problem: nicolaus:~ # rpm -Va --nofiles Unsatisfied dependencies for acroread-7.0.0-5.4: libcurl.so.2 This hasn't been there before. nicolaus:~ # rpm -ql curl /usr/bin/curl /usr/lib64/libcurl.la /usr/lib64/libcurl.so.2 /usr/lib64/libcurl.so.2.0.2 ...
mls and I found a solution for these 2 issues.
For nld - x86_64 we added glibc-locale-32bit to the selection file. That is how it works for 9.3-x86_64 also. Patching still would not work though because the base install would not have that other package... Is the solution you guys have good for x86_64 and i386? because it really should work for the same for i386 and not create a new x86_64 package that is really only i386 - as that is what it's compiled for at acrobat.
we use a trick with the YOU patch files. we have sets for i386 which just update the acroread package. the sets for x86_64 include the glibc-locale-32bit and curl-32bit packages and are specified as "UpdateOnlyInstalled: false", so if one of the packages is there, all 3 will be installed. The acroread for those is the exact one as used for i386.
Thats a nice way to handle it. I have one other issue, when I submitted this package to all the distributions I missed a tag Rudi added to the spec file: "NoSource: 0" I read a little about it but I don't understand the need except that it helps for encription laws or something? I've submitted the fixed package to STABLE, do we need to update the patch to have this in it for all the dist's?
nosource is for: - we do not want to ship the sourcecode (if it included patented stuff for instance) - its a pure binary tarball which we 1:1 repackage without information loss the latter is the case for acroreade ... it saved space on the CDs. I have published the updated for 9.0 -> 9.3 , sles 9, and nld 9 now. 8.2 discontinued, sles8 / ul1 / slec8 we can not upgrade, I also added this information to the security advisory. All is well -> resolved/fixed
CVE-2005-1625: CVSS v2 Base Score: 5.0 (AV:N/AC:L/Au:N/C:N/I:P/A:N)