<?xml version="1.0" encoding="UTF-8"?>
<!-- generator="FeedCreator 1.8" -->
<?xml-stylesheet href="http://update.proggen.org/lib/exe/css.php?s=feed" type="text/css"?>
<rdf:RDF
    xmlns="http://purl.org/rss/1.0/"
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
    xmlns:dc="http://purl.org/dc/elements/1.1/">
    <channel rdf:about="http://update.proggen.org/feed.php">
        <title>proggen.org security:memory-corruption:protection</title>
        <description></description>
        <link>http://update.proggen.org/</link>
        <image rdf:resource="http://update.proggen.org/lib/tpl/proggenY/images/favicon.ico" />
       <dc:date>2026-04-20T21:07:11+0200</dc:date>
        <items>
            <rdf:Seq>
                <rdf:li rdf:resource="http://update.proggen.org/doku.php?id=security:memory-corruption:protection:ascii-armor&amp;rev=1663868367"/>
                <rdf:li rdf:resource="http://update.proggen.org/doku.php?id=security:memory-corruption:protection:aslr&amp;rev=1663868367"/>
                <rdf:li rdf:resource="http://update.proggen.org/doku.php?id=security:memory-corruption:protection:cfi&amp;rev=1663868367"/>
                <rdf:li rdf:resource="http://update.proggen.org/doku.php?id=security:memory-corruption:protection:nx&amp;rev=1663868367"/>
                <rdf:li rdf:resource="http://update.proggen.org/doku.php?id=security:memory-corruption:protection:pie&amp;rev=1663868367"/>
                <rdf:li rdf:resource="http://update.proggen.org/doku.php?id=security:memory-corruption:protection:stack-protection&amp;rev=1663868367"/>
                <rdf:li rdf:resource="http://update.proggen.org/doku.php?id=security:memory-corruption:protection:static-analysis&amp;rev=1663868367"/>
                <rdf:li rdf:resource="http://update.proggen.org/doku.php?id=security:memory-corruption:protection:stdlib&amp;rev=1663868367"/>
            </rdf:Seq>
        </items>
    </channel>
    <image rdf:about="http://update.proggen.org/lib/tpl/proggenY/images/favicon.ico">
        <title>proggen.org</title>
        <link>http://update.proggen.org/</link>
        <url>http://update.proggen.org/lib/tpl/proggenY/images/favicon.ico</url>
    </image>
    <item rdf:about="http://update.proggen.org/doku.php?id=security:memory-corruption:protection:ascii-armor&amp;rev=1663868367">
        <dc:format>text/html</dc:format>
        <dc:date>2022-09-22T19:39:27+0200</dc:date>
        <dc:creator>Anonymous (anonymous@undisclosed.example.com)</dc:creator>
        <title>security:memory-corruption:protection:ascii-armor</title>
        <link>http://update.proggen.org/doku.php?id=security:memory-corruption:protection:ascii-armor&amp;rev=1663868367</link>
        <description>ASCII-Armored Addresses

The previous chapter about dangerous standard library functions revealed that many buffer overflows are caused by the incorrect handling of ASCII strings. Limiting this attack vector, Red Hat provided a patch for the Linux kernel that places executable code in low memory addresses. With all executable addresses containing a</description>
    </item>
    <item rdf:about="http://update.proggen.org/doku.php?id=security:memory-corruption:protection:aslr&amp;rev=1663868367">
        <dc:format>text/html</dc:format>
        <dc:date>2022-09-22T19:39:27+0200</dc:date>
        <dc:creator>Anonymous (anonymous@undisclosed.example.com)</dc:creator>
        <title>security:memory-corruption:protection:aslr</title>
        <link>http://update.proggen.org/doku.php?id=security:memory-corruption:protection:aslr&amp;rev=1663868367</link>
        <description>Address Space Layout Randomization (ASLR)

Memory corruption exploitation techniques depend on the knowledge of absolute addresses in the context of the running application. Introducing randomness to the memory layout of the process increases exploitation difficulty. One attempt to do so is Address Space Layout Randomization (ASLR). As an operating system feature ASLR is available on all modern platforms, but its effectiveness depends on the implementation and size of the address space</description>
    </item>
    <item rdf:about="http://update.proggen.org/doku.php?id=security:memory-corruption:protection:cfi&amp;rev=1663868367">
        <dc:format>text/html</dc:format>
        <dc:date>2022-09-22T19:39:27+0200</dc:date>
        <dc:creator>Anonymous (anonymous@undisclosed.example.com)</dc:creator>
        <title>security:memory-corruption:protection:cfi</title>
        <link>http://update.proggen.org/doku.php?id=security:memory-corruption:protection:cfi&amp;rev=1663868367</link>
        <description>Tice, Caroline, et al.</description>
    </item>
    <item rdf:about="http://update.proggen.org/doku.php?id=security:memory-corruption:protection:nx&amp;rev=1663868367">
        <dc:format>text/html</dc:format>
        <dc:date>2022-09-22T19:39:27+0200</dc:date>
        <dc:creator>Anonymous (anonymous@undisclosed.example.com)</dc:creator>
        <title>security:memory-corruption:protection:nx</title>
        <link>http://update.proggen.org/doku.php?id=security:memory-corruption:protection:nx&amp;rev=1663868367</link>
        <description>NX Bit

The memory of a process is divided into different segments. Roughly speaking, memory regions are distinguished by whether they contain data or executable code. Memory pages which are intended to store data are labeled with the No-eXecute (NX) bit. In case an application tries to execute code located in such a page, an error is raised.</description>
    </item>
    <item rdf:about="http://update.proggen.org/doku.php?id=security:memory-corruption:protection:pie&amp;rev=1663868367">
        <dc:format>text/html</dc:format>
        <dc:date>2022-09-22T19:39:27+0200</dc:date>
        <dc:creator>Anonymous (anonymous@undisclosed.example.com)</dc:creator>
        <title>security:memory-corruption:protection:pie</title>
        <link>http://update.proggen.org/doku.php?id=security:memory-corruption:protection:pie&amp;rev=1663868367</link>
        <description>Position-independent Executable (PIE)

The protection mechanism ASLR was explained in the previous chapter. It introduces randomness to the memory layout of processes. Thus it is harder for attackers to correctly organize exploit execution. However, remember that even with ASLR fully enabled, the executable itself as well as the PLT are still not randomized. Position-independent Code (PIC) is a compiler feature which produces code that can be loaded at arbitrary addresses. Binaries consisting of…</description>
    </item>
    <item rdf:about="http://update.proggen.org/doku.php?id=security:memory-corruption:protection:stack-protection&amp;rev=1663868367">
        <dc:format>text/html</dc:format>
        <dc:date>2022-09-22T19:39:27+0200</dc:date>
        <dc:creator>Anonymous (anonymous@undisclosed.example.com)</dc:creator>
        <title>security:memory-corruption:protection:stack-protection</title>
        <link>http://update.proggen.org/doku.php?id=security:memory-corruption:protection:stack-protection&amp;rev=1663868367</link>
        <description>Stack Protection

Modern compilers provide stack protection mechanism that can be compiled into a binary.

Looking at GCC, it provides different flags to enable stack protection for functions. Using the -fstack-protector flag during compilation makes GCC supply every function with a buffer of at least 8 bytes.</description>
    </item>
    <item rdf:about="http://update.proggen.org/doku.php?id=security:memory-corruption:protection:static-analysis&amp;rev=1663868367">
        <dc:format>text/html</dc:format>
        <dc:date>2022-09-22T19:39:27+0200</dc:date>
        <dc:creator>Anonymous (anonymous@undisclosed.example.com)</dc:creator>
        <title>security:memory-corruption:protection:static-analysis</title>
        <link>http://update.proggen.org/doku.php?id=security:memory-corruption:protection:static-analysis&amp;rev=1663868367</link>
        <description>M. Alvares, T. Marwala and F. B. de Lima Neto, „Applications of computational intelligence for static software checking against memory corruption vulnerabilities,</description>
    </item>
    <item rdf:about="http://update.proggen.org/doku.php?id=security:memory-corruption:protection:stdlib&amp;rev=1663868367">
        <dc:format>text/html</dc:format>
        <dc:date>2022-09-22T19:39:27+0200</dc:date>
        <dc:creator>Anonymous (anonymous@undisclosed.example.com)</dc:creator>
        <title>security:memory-corruption:protection:stdlib</title>
        <link>http://update.proggen.org/doku.php?id=security:memory-corruption:protection:stdlib&amp;rev=1663868367</link>
        <description>Dangerous Standard Library Functions and Safer Alternatives

The previous chapters explained different buffer overflow exploitation techniques. However, the overflows themselves did not happen in self-written code, but in standard library functions which were called with insufficiently validated parameters. We can see that one does not only need to be careful about writing safe code but also about using provided functions that make assumptions about the passed input. The standard library of the …</description>
    </item>
</rdf:RDF>
