From sacadmin Fri Jun 29 15:04:29 2007 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5TM4TsF023408; Fri, 29 Jun 2007 15:04:29 -0700 (PDT) Received: (from ab196087@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l5TM4T2i023404; Fri, 29 Jun 2007 15:04:29 -0700 (PDT) Date: Fri, 29 Jun 2007 15:04:29 -0700 (PDT) From: Ali Bahrami Message-Id: <200706292204.l5TM4T2i023404@sac.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: Add -P option to elfdump [PSARC/2007/395 FastTrack timeout 07/11/2007] Status: RO Content-Length: 556 Template Version: @(#)sac_nextcase 1.63 06/14/07 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Add -P option to elfdump 1.2. Name of Document Author/Supplier: Author: Ali Bahrami 1.3 Date of This Document: 29 June, 2007 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: on 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From sacadmin Fri Jun 29 15:12:12 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5TMCCLi023463 for ; Fri, 29 Jun 2007 15:12:12 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5TMAPT8008788 for ; Fri, 29 Jun 2007 15:10:25 -0700 (PDT) Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5TMAPlL000661 for ; Fri, 29 Jun 2007 22:10:25 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JKF00L013YK7Q00@mail-amer.sun.com> (original mail from Ali.Bahrami@Sun.COM) for psarc@sac.sfbay.sun.com; Fri, 29 Jun 2007 16:10:25 -0600 (MDT) Received: from [172.20.25.67] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JKF001C849DQF15@mail-amer.sun.com> for psarc@sac.sfbay.sun.com; Fri, 29 Jun 2007 16:10:25 -0600 (MDT) Date: Fri, 29 Jun 2007 16:07:56 -0600 From: Ali Bahrami Subject: PSARC/2007/395 Add -P option to elfdump Sender: Ali.Bahrami@Sun.COM To: psarc@sac.sfbay.sun.com Message-id: <468582BC.9080307@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5.0.10 (X11/20070303) Status: RO Content-Length: 4190 I am sponsoring the following fast track for myself - timeout 7/11/2007 --------------------------------------------------------------------------- This case proposes a new command line option (-P) to elfdump. If an object without section headers is encountered, or if the user specifies -P, elfdump will use the program headers to synthesize a set of section headers, and will then use those generated headers instead of the actual ones to generate its output. This feature improves our ability to analyze ELF objects in which the section headers have been stripped, or altered. It does not otherwise alter elfdump behavior or output. This change is my solution to: 6530249 elfdump should handle ELF files with no section header table Background Information ---------------------- ELF files contain two different types of header records. Section headers provide detailed information about every section found in a given object, whether or not they are mapped as part of an executable process. Linkers, debuggers and diagnostic tools rely on this information. Program headers provide only the information needed by the exec() system call, and the runtime linker, to load and execute a program. A malicious person can remove or corrupt section headers. The resulting program will be difficult to analyze, but is still runnable. Hence, scribbling on the section headers or removing them is an effective form of obfuscation. An example of this is the recent worm that exploited a vulnerability in the Solaris telnet daemon. The author of that worm stripped the section headers from the executable file, limiting our ability to examine it with the elfdump utility. In contrast, program headers must be relatively accurate or the program will not run. In particular, calls to routines in system libraries (such as libc) cannot be disguised, since the runtime linker looks these up by name. Program headers access much of the same data as section headers, especially through the PT_DYNAMIC header, which points to the dynamic section used to convey information to the runtime linker (ld.so.1). This leads to the idea of using the program headers to construct a synthetic set of section headers, rather than relying on the actual section headers. These fake section headers will necessarily lack information found in the originals (particularly for non-allocable sections), but will provide essential symbol information. The focus is on recovering information that elfdump knows how to display, and that might be interesting in a forensic situation. The ability to generate and use section headers derived from the program headers is clearly useful in a case such as the telnet worm, where the section headers are completely missing. However, it can also be valuable in the case where there is reason to suspect that the section headers have been tampered with to provide misleading information. By using elfdump with and without the -P option on such a file and comparing the results, it is possible to detect many such changes. In an "arms race" situation such as this, we cannot pretend that our response is the last word, or that a bad person won't find another new way to circumvent our ability to analyze their work. Indeed, some information is only accessible via section headers, and there is no easy way to recover that. Despite that, this feature will be a useful tool in such situations. Supporting Materials -------------------- Webrev for this change can be viewed within SWAN at: http://linkers.central/webrev/6530249/index.html To show what the -P option can do, I've placed some elfdump output in the case materials subdirectory: [worm.old_elfdump] Telnet worm, as reported by the stock elfdump [worm.new_elfdump] Telnet worm, as reported by the new elfdump [elfdump.std] Standard elfdump output for the new elfdump binary [elfdump.fake] -P elfdump output for the new elfdump binary Those last 2 allow you to compare results on the same file, to see what is lost in -P mode, and what survives. --------------------------------------------------------------------------- Release Binding: Patch/Micro -P elfdump option: Committed From Ali.Bahrami@sun.com Fri Jun 29 15:39:21 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5TMdLrh024574 for ; Fri, 29 Jun 2007 15:39:21 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5TMbY42016574 for <@sunmail3mpk.sfbay.sun.com:psarc-ext@sun.com>; Fri, 29 Jun 2007 15:37:35 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JKF00H0J5IM6D00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 29 Jun 2007 15:37:34 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKF0097K5ILA060@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 29 Jun 2007 15:37:33 -0700 (PDT) Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5TMbX0u005641 for ; Fri, 29 Jun 2007 22:37:33 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JKF000014U2NG00@mail-amer.sun.com> (original mail from Ali.Bahrami@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 29 Jun 2007 16:37:33 -0600 (MDT) Received: from [172.20.25.67] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JKF001UM5IKQF15@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 29 Jun 2007 16:37:33 -0600 (MDT) Date: Fri, 29 Jun 2007 16:35:04 -0600 From: Ali Bahrami Subject: PSARC/2007/395 Add -P option to elfdump Sender: Ali.Bahrami@sun.com To: psarc-ext@sun.com Message-id: <46858918.30509@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 1.5.0.10 (X11/20070303) Status: RO Content-Length: 4306 [Apologies if you see this twice. This is an open case --- Resending to psarc-ext] I am sponsoring the following fast track for myself - timeout 7/11/2007 --------------------------------------------------------------------------- This case proposes a new command line option (-P) to elfdump. If an object without section headers is encountered, or if the user specifies -P, elfdump will use the program headers to synthesize a set of section headers, and will then use those generated headers instead of the actual ones to generate its output. This feature improves our ability to analyze ELF objects in which the section headers have been stripped, or altered. It does not otherwise alter elfdump behavior or output. This change is my solution to: 6530249 elfdump should handle ELF files with no section header table Background Information ---------------------- ELF files contain two different types of header records. Section headers provide detailed information about every section found in a given object, whether or not they are mapped as part of an executable process. Linkers, debuggers and diagnostic tools rely on this information. Program headers provide only the information needed by the exec() system call, and the runtime linker, to load and execute a program. A malicious person can remove or corrupt section headers. The resulting program will be difficult to analyze, but is still runnable. Hence, scribbling on the section headers or removing them is an effective form of obfuscation. An example of this is the recent worm that exploited a vulnerability in the Solaris telnet daemon. The author of that worm stripped the section headers from the executable file, limiting our ability to examine it with the elfdump utility. In contrast, program headers must be relatively accurate or the program will not run. In particular, calls to routines in system libraries (such as libc) cannot be disguised, since the runtime linker looks these up by name. Program headers access much of the same data as section headers, especially through the PT_DYNAMIC header, which points to the dynamic section used to convey information to the runtime linker (ld.so.1). This leads to the idea of using the program headers to construct a synthetic set of section headers, rather than relying on the actual section headers. These fake section headers will necessarily lack information found in the originals (particularly for non-allocable sections), but will provide essential symbol information. The focus is on recovering information that elfdump knows how to display, and that might be interesting in a forensic situation. The ability to generate and use section headers derived from the program headers is clearly useful in a case such as the telnet worm, where the section headers are completely missing. However, it can also be valuable in the case where there is reason to suspect that the section headers have been tampered with to provide misleading information. By using elfdump with and without the -P option on such a file and comparing the results, it is possible to detect many such changes. In an "arms race" situation such as this, we cannot pretend that our response is the last word, or that a bad person won't find another new way to circumvent our ability to analyze their work. Indeed, some information is only accessible via section headers, and there is no easy way to recover that. Despite that, this feature will be a useful tool in such situations. Supporting Materials -------------------- Webrev for this change can be viewed within SWAN at: http://linkers.central/webrev/6530249/index.html To show what the -P option can do, I've placed some elfdump output in the case materials subdirectory: [worm.old_elfdump] Telnet worm, as reported by the stock elfdump [worm.new_elfdump] Telnet worm, as reported by the new elfdump [elfdump.std] Standard elfdump output for the new elfdump binary [elfdump.fake] -P elfdump output for the new elfdump binary Those last 2 allow you to compare results on the same file, to see what is lost in -P mode, and what survives. --------------------------------------------------------------------------- Release Binding: Patch/Micro -P elfdump option: Committed From Ali.Bahrami@sun.com Wed Jul 11 13:37:59 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l6BKbxQ6006910 for ; Wed, 11 Jul 2007 13:37:59 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6BKa20g000742 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 11 Jul 2007 13:36:04 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JL100A0X7W35D00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 11 Jul 2007 13:36:03 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JL1004FZ7W25F30@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 11 Jul 2007 13:36:02 -0700 (PDT) Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6BKa281007013 for ; Wed, 11 Jul 2007 20:36:02 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JL100K0177ZQK00@mail-amer.sun.com> (original mail from Ali.Bahrami@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 11 Jul 2007 14:36:02 -0600 (MDT) Received: from [172.20.25.67] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JL10041M7W1DMI3@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 11 Jul 2007 14:36:02 -0600 (MDT) Date: Wed, 11 Jul 2007 14:33:33 -0600 From: Ali Bahrami Subject: Re: PSARC/2007/395 Add -P option to elfdump In-reply-to: <46858918.30509@Sun.COM> Sender: Ali.Bahrami@sun.com To: Ali Bahrami Cc: psarc-ext@sun.com Message-id: <46953E9D.5010605@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46858918.30509@Sun.COM> User-Agent: Thunderbird 1.5.0.10 (X11/20070303) Status: RO Content-Length: 60 This case was approved during today's PSARC meeting. - Ali