BUFFER OVERFLOW 3
An Assembly Language
IntroductionBasic of x86 ArchitectureAssembly LanguageCompiler, Assembler & LinkerFunction OperationStackStack OperationStack based Buffer OverflowShellcode: The PayloadVulnerability & Exploit Examples |
THE ASSEMBLY LANGUAGESome knowledge of assembly is necessary in order to understand the operation of the buffer overflow exploits. There are essentially three kinds of languages:
Assembly is a symbolic language that is assembled into machine language by an assembler. In other words, assembly is a mnemonic statement that corresponds directly to processor-specific instructions. Each type of processor has its own instruction set and thus its own assembly language. Assembly deals directly with the registers of the processor and memory locations. There are some general rules that are typically true for most assembly languages are listed below:
|
|||||||||||||||
Opcodes are the actual instructions that a program performs. Each opcode is represented by one line of code, which contains the opcode and the operands that are used by the opcode. The number of operands varies depending on the opcode. The entire suite of opcodes available to a processor is called an instruction set. Depending on the processor, OS, and disassembler used, the operands may be in reverse order. For example, on Windows:
MOV dst, src
Is equivalent to:
MOV %src, %dst on Linux.
Windows uses Intel assembly whereas Linux uses AT&T assembly. Another one you may find is Mac OS (PowerPC) that is Motorola processor instruction set. High Level Assembly (HLA) also quite popular among programmers. This paper will use both Windows and AT&T assembly. Whatever assembly used, there are several common categories of instructions based on their usages as listed in the following Table.
|
Instruction Category |
Meaning |
Example |
|
Data Transfer |
move from source to destination |
mov, lea, les, push, pop, pushf, popf |
|
Arithmetic |
arithmetic on integers |
add, adc, sub, sbb, mul, imul, div, idiv, cmp, neg, inc, dec, xadd, cmpxchg |
|
Floating point |
arithmetic on floating point |
fadd, fsub, fmul, div, cmp |
|
Logical, Shift, Rotate and Bit |
bitwise logic operations |
and, or, xor, not, shl/sal, shr, sar, shld and shrd, ror, rol, rcr andrcl |
|
Control transfer |
conditional and unconditional jumps, procedure calls |
jmp, jcc, call, ret, int, into, bound. |
|
String |
move, compare, input and output |
movs, lods, stos, scas, cmps, outs, rep, repz, repe, repnz, repne,ins |
|
I/O |
For input and output |
in, out |
|
Conversion |
Provide assembly data types conversion |
movzx, movsx, cbw, cwd, cwde, cdq, bswap, xlat |
|
Miscellaneous |
manipulate individual flags, provide special processor services, or handle privileged mode operations |
clc, stc, cmc, cld, std, cl, sti |
|
Table 2: Assembly instruction set categories. |
||
The following is C source code portion and the assembly equivalent example using Linux/Intel.
|
C code’s portion |
Label |
Mnemonic |
operands |
Comment |
|
if (a > b) |
movl |
a, %eax |
||
|
cmpl |
b, %eax |
#compare, a – b |
||
|
jle |
L1 |
#jump to L1 if a <= b |
||
|
c = a; |
movl |
a, %eax |
#a > b branch |
|
|
movl |
%eax, c |
|||
|
jmp |
L2 |
#finish, jump to L2 |
||
|
L1: |
#a <= b branch |
|||
|
else c = b; |
movl |
b, %eax |
||
|
movl |
%eax, c |
|||
|
L2: |
#Finish |
Figure 1: C and assembly codes.
Compilers available for assembly languages include Macro Assembler (MASM), GNU’s Assembler (GAS wiki, GAS manual), Borland’s TASM, Netwide (NASM) and GoASM. For HLA it is available from Webster at HLA.
COMPILER, ASSEMBLER, LINKER AND LOADER
Normally the C’s program building process involves four stages and utilizes different tools such as a preprocessor, compiler, assembler, and linker. At the end there should be a single executable image that ready to be loaded by loader as a running program. Below are the stages that happen in order regardless of the operating system/compiler and graphically illustrated in Figure 2.
- Preprocessing is the first pass of any C compilation. It processes include-files, conditional compilation instructions and macros.
- Compilation is the second pass. It takes the output of the preprocessor, and the source code, and generates assembler source code.
- Assembly is the third stage of compilation. It takes the assembly source code and produces an assembly listing with offsets. The assembler output is stored in an object file.
- Linking is the final stage of compilation. It takes one or more object files or libraries as input and combines them to produce a single (usually executable) file. In doing so, it resolves references to external symbols, assigns final addresses to procedures/functions and variables, and revises code and data to reflect new addresses (a process called relocation).
- Loading the executable image for program running.
Bear in mind that if you use the Integrated Development Environment (IDE) type compilers, these processes quite transparent. Now we are going to examine more detail about the process that happens before and after the linking stage. For any given input file, the file name suffix (file extension) determines what kind of compilation is done and the example for gcc is listed in Table 3.
|
File extension |
Description |
|
file_name.c |
C source code which must be preprocessed. |
|
file_name.i |
C source code which should not be preprocessed. |
|
file_name.ii |
C++ source code which should not be preprocessed. |
|
file_name.h |
C header file (not to be compiled or linked). |
|
file_name.cc file_name.cp file_name.cxx file_name.cpp file_name.c++ file_name.C |
C++ source code which must be preprocessed. For file_name.cxx, the xx must both be literally character x and file_name.C, is capital c. |
|
file_name.s |
Assembler code. |
|
file_name.S |
Assembler code which must be preprocessed. |
|
file_name.o |
By default, the object file name for a source file is made by replacing the extension .c, .i, .s etc with .o |
|
Table 3: File suffix. |
|
The following Figure shows the steps involved in the process of building the C program starting from the compilation until the loading of the executable image into the memory for program running.
Figure 2: C program building process.
OBJECT FILES AND EXECUTABLE
After the source code has been assembled, it will produce an object files and then linked, producing an executable files. An object and executable come in several formats such as ELF (Executable and Linking Format) and COFF (Common Object-File Format). For example, ELF is used on Linux systems, while COFF is used on Windows systems. Other object file formats that you may find sometime somewhere is listed in the following Table.
Object File Format |
Description |
|
a.out |
The a.out format is the original file format for Unix. It consists of three sections: text, data, and bss, which are for program code, initialized data, and uninitialized data, respectively. This format is so simple that it doesn‘t have any reserved place for debugging information. The only debugging format for a.out is stabs, which is encoded as a set of normal symbols with distinctive attributes.
|
|
COFF |
The COFF (Common Object File Format) format was introduced with System V Release 3 (SVR3) Unix. COFF files may have multiple sections, each prefixed by a header. The number of sections is limited. The COFF specification includes support for debugging but the debugging information was limited. |
|
ECOFF |
A variant of COFF. ECOFF is an Extended COFF originally introduced for Mips and Alpha workstations. |
|
XCOFF |
The IBM RS/6000 running AIX uses an object file format called XCOFF (eXtended COFF). The COFF sections, symbols, and line numbers are used, but debugging symbols are dbx-style stabs whose strings are located in the .debug section (rather than the string table). The default name for an XCOFF executable file is a.out.
|
|
PE |
Windows 9x and NT use the PE (Portable Executable) format for their executables. PE is basically COFF with additional headers. |
|
ELF |
The ELF (Executable and Linking Format) format came with System V Release 4 (SVR4) Unix. ELF is similar to COFF in being organized into a number of sections, but it removes many of COFF‘s limitations. ELF used on most modern Unix systems, including GNU/Linux, Solaris and Irix. Also used on many embedded systems. |
|
SOM/ESOM |
SOM (System Object Module) and ESOM (Extended SOM) is HP‘s object file and debug format (not to be confused with IBM‘s SOM, which is a cross-language Application Binary Interface - ABI). |
|
Table 4: Object file formats. |
|
|
When we examine the content of these object files there are areas called sections. Depend on the settings of the compilation and linking stages, sections can hold:
Some sections are loaded into the process image and some provide information needed in the building of a process image while still others are used only in linking object files. There are several sections that are common to all executable formats (may be named differently, depending on the compiler/linker) as listed below: |
|
Section |
Description |
|
.text |
This section contains the executable instruction codes and is shared among every process running the same binary. This section usually has READ and EXECUTE permissions only. This section is the one most affected by optimization. |
|
.bss |
BSS stands for ‘Block Started by Symbol’. It holds un-initialized global and static variables. Since the BSS only holds variables that don‘t have any values yet, it doesn‘t actually need to store the image of these variables. The size that BSS will require at runtime is recorded in the object file, but the BSS (unlike the data section) doesn‘t take up any actual space in the object file. |
|
.data |
Contains the initialized global and static variables and their values. It is usually the largest part of the executable. It usually hasREAD/WRITE permissions. |
|
.rdata |
Also known as .rodata (read-only data) section. This contains constants and string literals. |
|
.reloc |
Stores the information required for relocating the image while loading. |
|
Symbol table |
A symbol is basically a name and an address. Symbol table holds information needed to locate and relocate a program’s symbolic definitions and references. A symbol table index is a subscript into this array. Index 0 both designates the first entry in the table and serves as the undefined symbol index. The symbol table contains an array of symbol entries. |
|
Relocation records |
Relocation is the process of connecting symbolic references with symbolic definitions. For example, when a program calls a function, the associated call instruction must transfer control to the proper destination address at execution. Relocatable files must have relocation entries’ which are necessary because they contain information that describes how to modify their section contents, thus allowing executable and shared object files to hold the right information for a process‘s program image. Simply said relocation records are information used by the linker to adjust section contents. |
|
Table 5: Segments in executable file. |
|
The following is an example of the object file content dumped using readelf program (how to use the command was discussed in GCC & G++ 1 and GCC & G++ 2). Other program can be used is objdump. For Windows, dumpbin utility (coming with Visual C++ compiler) program can be used for the same purpose.
/* testprog1.c */
#include <stdio.h>
static void display(int i, int *ptr);
int main(void)
{
int x = 5;
int *xptr = &x;
printf("In main() program:\n");
printf("x value is %d and is stored at address %p.\n", x, &x);
printf("xptr pointer points to address %p which holds a value of %d.\n", xptr, *xptr);
display(x, xptr);
return 0;
}
void display(int y, int *yptr)
{
char var[7] = "ABCDEF";
printf("In display() function:\n");
printf("y value is %d and is stored at address %p.\n", y, &y);
printf("yptr pointer points to address %p which holds a value of %d.\n", yptr, *yptr);
}
[[email protected] test]$ gcc -c testprog1.c
[[email protected] test]$ readelf -a testprog1.o
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2‘s complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: REL (Relocatable file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0x0
Start of program headers: 0 (bytes into file)
Start of section headers: 672 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 40 (bytes)
Number of section headers: 11
Section header string table index: 8
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 00000000 000034 0000de 00 AX 0 0 4
[ 2] .rel.text REL 00000000 00052c 000068 08 9 1 4
[ 3] .data PROGBIT 00000000 000114 000000 00 WA 0 0 4
[ 4] .bss NOBIT 00000000 000114 000000 00 WA 0 0 4
[ 5] .rodata PROGBITS 00000000 000114 00010a 00 A 0 0 4
[ 6] .note.GNU-stack PROGBITS 00000000 00021e 000000 00 0 0 1
[ 7] .comment PROGBITS 00000000 00021e 000031 00 0 0 1
[ 8] .shstrtab STRTAB 00000000 00024f 000051 00 0 0 1
[ 9] .symtab SYMTAB 00000000 000458 0000b0 10 10 9 4
[10] .strtab STRTAB 00000000 000508 000021 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
There are no program headers in this file.
Relocation section ‘.rel.text‘ at offset 0x52c contains 13 entries:
Offset Info Type Sym.Value Sym. Name
0000002d 00000501 R_386_32 00000000 .rodata
00000032 00000a02 R_386_PC32 00000000 printf
00000044 00000501 R_386_32 00000000 .rodata
00000049 00000a02 R_386_PC32 00000000 printf
0000005c 00000501 R_386_32 00000000 .rodata
00000061 00000a02 R_386_PC32 00000000 printf
0000008c 00000501 R_386_32 00000000 .rodata
0000009c 00000501 R_386_32 00000000 .rodata
000000a1 00000a02 R_386_PC32 00000000 printf
000000b3 00000501 R_386_32 00000000 .rodata
000000b8 00000a02 R_386_PC32 00000000 printf
000000cb 00000501 R_386_32 00000000 .rodata
000000d0 00000a02 R_386_PC32 00000000 printf
There are no unwind sections in this file.
Symbol table ‘.symtab‘ contains 11 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000000 0 FILE LOCAL DEFAULT ABS testprog1.c
2: 00000000 0 SECTION LOCAL DEFAULT 1
3: 00000000 0 SECTION LOCAL DEFAULT 3
4: 00000000 0 SECTION LOCAL DEFAULT 4
5: 00000000 0 SECTION LOCAL DEFAULT 5
6: 00000080 94 FUNC LOCAL DEFAULT 1 display
7: 00000000 0 SECTION LOCAL DEFAULT 6
8: 00000000 0 SECTION LOCAL DEFAULT 7
9: 00000000 128 FUNC GLOBAL DEFAULT 1 main
10: 00000000 0 NOTYPE GLOBAL DEFAULT UND printf
No version information found in this file.
When writing a program using the assembly language it should be compatible with the sections in the assembler directives (x86) and the partial list that is interested to us is listed below:
|
Section |
Description |
|
|
1 |
Text (.section .text) |
Contain code (instructions). Contain the _start label. |
|
2 |
Read-Only Data (.section .rodata) |
Contains pre-initialized constants. |
|
3 |
Read-Write Data (.section .data) |
Contains pre-initialized variables. |
|
4 |
BSS (.section .bss) |
Contains un-initialized data. |
|
Table 6: Some sections in object file. |
||
The assembler directives in assembly programming can be used to identify code and data sections, allocate/initialize memory and making symbols externally visible or invisible. An example of the assembly code with some of the assembler directives (Intel) is shown below:
|
;initializing data |
|||
|
.section |
.data |
||
|
x: |
.byte |
128 |
;one byte initialized to 128 |
|
y: |
.long |
1,1000,10000 |
;3 long words |
|
;initializing ascii data |
|||
|
.ascii |
"hello" |
;ascii without null character |
|
|
asciz |
"hello" |
;ascii with \0 |
|
|
;allocating memory in bss |
|||
|
.section |
.bss |
||
|
.equ |
BUFFSIZE 1024 |
;define a constant |
|
|
.comm |
z, 4, 4 |
;allocate 4 bytes for x with 4-byte alignment |
|
|
;making symbols externally visible |
|||
|
.section |
.data |
||
|
.globl |
w |
;declare externally visible e.g: int w = 10 |
|
|
.text |
|||
|
.globl |
fool |
;e.g: fool(void) {…} |
|
|
fool: |
|||
|
… |
|||
|
leave |
|||
|
return |
|||