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
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
/proc/
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 74 / 75
GNU Debugger Mini Tutorial
run
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
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