atom.xml

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">

  <title><![CDATA[My Octopress Blog]]></title>
  <link href="http://movingname.github.io/atom.xml" rel="self"/>
  <link href="http://movingname.github.io/"/>
  <updated>2013-06-30T18:46:05-04:00</updated>
  <id>http://movingname.github.io/</id>
  <author>
    <name><![CDATA[Your Name]]></name>
    
  </author>
  <generator uri="http://octopress.org/">Octopress</generator>

  
  <entry>
    <title type="html"><![CDATA[Return-to-libc-Attack]]></title>
    <link href="http://movingname.github.io/blog/2013/06/30/return-to-libc-attack/"/>
    <updated>2013-06-30T18:45:00-04:00</updated>
    <id>http://movingname.github.io/blog/2013/06/30/return-to-libc-attack</id>
    <content type="html"><![CDATA[<p>This post records my effort to study return-to-libc attack.
Hope you will find some of the content helpful.</p>

<h2>Introduction</h2>

<p>Return-to-libc attack is an advanced form of the &ldquo;classical&rdquo; buffer overflow attack.
Unlike the classical buffer overflow attack, return-to-libc attack does not require
an executable stack to hold injected shellcode. Instead, it reuse existing codes(such as libc)
inside the victim system to achieve the attacker&rsquo;s goals.</p>

<p>To launch a Return-to-libc attack, the attacker will overwrite the return address of current
stack frame to be the address of a libc function, such as system(). The attacker also needs to
overwrite desired parameters to the right memory location.</p>

<p>For example, if the return address points to system() and the parameter is &ldquo;/bin/sh&rdquo;, then the
victim system actually executes system(&ldquo;/bin/sh&rdquo;) to invoke a shell when the vulnerable function
returns. If the program has root privilege(<em>TODO</em>: check), the newly invoked shell might also has
root privilege and is controlled by the attacker.</p>

<h2>Practice</h2>

<p>We can use SEED lab to practice a return-to-libc attack. Here, I will
provide some tips for finishing the lab. So please first read the document
provided in <a href="http://www.cis.syr.edu/~wedu/seed/Labs/Vulnerability/Return_to_libc/">SEED-rlibc</a>.</p>

<p><strong>(Tip 1)</strong>. To know exactly where the buffer locates, we can use gdb to debug the
vulnerable program. The following commands will be useful:</p>

<ul>
<li>info frame, see <a href="http://www.chemie.fu-berlin.de/chemnet/use/info/gdb/gdb_7.html">GDB-stack</a></li>
<li>x\nfw <em>addr</em>, see <a href="http://www.delorie.com/gnu/docs/gdb/gdb_56.html">GDB-examine</a></li>
</ul>


<p><strong>(Tip 2)</strong>. When creating the badfile, we can use the od -x <em>filename</em> command to
output the badfile in hex.</p>

<p><strong>(Tip 3)</strong>. To get the correct result, please spend enough time reading 3.3 of
the lab document.</p>

<p><strong>(Unsolved Question 1)</strong>. I used several test to find out the address of MYSHELL.
Can I directly get the address of that variable?</p>

<ul>
<li><p>The first idea is to use gdb to display the memory area holding environment variables.
However, gdb says that I do not have the permission.</p></li>
<li><p>The second idea coms from a <a href="http://security.stackexchange.com/questions/13194/finding-environment-variables-with-gdb-to-exploit-a-buffer-overflow">stackOverflow thread</a>. But it does not work for me.</p></li>
</ul>


<h2>References</h2>
]]></content>
  </entry>
  
</feed>