swift 05/06/08 19:09:16 Added: xml/htdocs/doc/en/handbook/draft pax-utils.xml Log: On request of solar, starting a pax-utils document. Still in DRAFT ! Committed to CVS in case my second computer fails as well :p
Revision Changes Path 1.1 xml/htdocs/doc/en/handbook/draft/pax-utils.xml file : http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/handbook/draft/pax-utils.xml?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=gentoo plain: http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/handbook/draft/pax-utils.xml?rev=1.1&content-type=text/plain&cvsroot=gentoo Index: pax-utils.xml =================================================================== <?xml version='1.0' encoding="UTF-8"?> <!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/handbook/draft/pax-utils.xml,v 1.1 2005/06/08 19:09:16 swift Exp $ --> <!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> <guide link="/doc/en/pax-utils.xml"> <title>Gentoo Pax Utils</title> <author title="Author"> <mail link="[EMAIL PROTECTED]">Sven Vermeulen</mail> </author> <author title="Editor"> <mail link="[EMAIL PROTECTED]">Ned Ludd</mail> </author> <abstract> </abstract> <!-- The content of this document is licensed under the CC-BY-SA license --> <!-- See http://creativecommons.org/licenses/by-sa/2.0 --> <license/> <version>0.1</version> <date>2005-01-01</date> <chapter> <title>What is this guide about?</title> <section> <title>Introduction</title> <body> <p> The security of a system goes beyond firewalling and good service configurations. The binaries you run, the libraries you load, might also be vulnerable against attacks. Although the exact vulnerabilities are not known until they are discovered, there are ways to prevent them from happening. </p> <p> One possible attack vector is to make advantage of writeable <e>and</e> executable segments in a program or library, allowing malafide users to run their own code using the vulnerable application or library. </p> <p> This guide will inform you how to use the <c>pax-utils</c> package to find and identify problematic binaries. We will also cover the use of <c>pspax</c> (a tool to view PAX-specific capabilities) and <c>dumpelf</c> (a tool that prints out a C structure containing a workeable copy of a given object). </p> <p> But before we start with that, some information on <e>objects</e> is in place. Users familiar with segments and dynamic linking will not learn anything from this and can immediately continue with <uri link="#scanelf">Extracting ELF Information from Binaries</uri>. </p> </body> </section> <section> <title>ELF objects</title> <body> <p> Every executable binary on your system is structured in a specific way, allowing the Linux kernel to load and execute the file. Actually, this goes beyond plain executable binaries: this also holds for shared objects; more about those later. </p> <p> The structure of such a binary is defined in the ELF standard. ELF stands for <e>Executable and Linkable Format</e>. If you are really interested in the gory details, check out the <c>elf</c> man page. </p> <p> An executable ELF file has the following parts: </p> <ul> <li> The <e>ELF header</e> contains information on the <e>type</e> of file (is it an executable, a shared library, ...), the target architecture, the location of the Program Header, Section Header and String Header in the file and the location of the first executable instruction </li> <li> The <e>Program Header</e> informs the system how to create a process from the binary file. It is actually a table consisting of entries for each segment in the program. Each entry contains the type, addresses (fysical and virtual), size, ... </li> <li> The <e>Section Header</e> is a table consisting of entries for each section in the program. Each entry contains the name, type, size, ... and also <e>what</e> information the section holds. </li> <li> Data, containing the sections and segments mentioned previously. </li> </ul> <p> A <e>section</e> is a small unit consisting of specific data: instructions, variable data, symbol table, relocation information, and so on. A <e>segment</e> is a collection of sections; segments are the units that are actually transferred to memory. </p> </body> </section> <section> <title>Shared Objects</title> <body> <p> Originally, every application binary contained <e>everything</e> it needed to operate correctly. Such binaries are called <e>statically linked</e> binaries. They are however space consuming since many applications use the same functions over and over again. </p> <p> A <e>shared object</e> contains the definition and instructions for such functions. Every application that wants can <e>dynamically</e> link against such a shared object so that it can benefit from the already existing functionality. </p> <p> An application that is dynamically linked to a shared object contains <e>symbols</e>, substitutes for the real functionality. When such an application is loaded in memory, it will first ask the runtime linker to resolve each and every symbol it has. The runtime linker will load the appropriate shared objects in memory and return their location to the application. </p> </body> </section> <section> <title>Segments</title> <body> <p> An application (or shared object) has several predefined segments. Summing them all up is beyond the scope of this document, but a few do need to be mentioned as they are used further in this guide: </p> <ul> <li>The <c>text</c> segment contains executable code</li> <li>The <c>data</c> segment contains program data</li> <li> The <c>dynamic</c> segment contains information relevant to dynamic linking </li> </ul> </body> </section> </chapter> <chapter id="scanelf"> <title>Extracting ELF Information from Binaries</title> <section> <title>The scanelf Application</title> <body> <p> The <c>scanelf</c> application is part of the <c>app-misc/pax-utils</c> package. With this application you can print out information specific to the ELF structure of a binary. The following table sums up the various options. </p> <table> <tr> <th>Option</th> <th>Long Option</th> <th>Description</th> </tr> <tr> <ti>-p</ti> <ti>--path</ti> <ti>Scan all directories in the PATH environment</ti> </tr> <tr> <ti>-l</ti> <ti>--ldpath</ti> <ti>Scan all directories mentioned in <path>/etc/ld.so.conf</path></ti> </tr> <tr> <ti>-R</ti> <ti>--recursive</ti> <ti>Scan directories recursively</ti> </tr> <tr> <<Truncated>> -- [email protected] mailing list
