3 ms·
Well, FORTIFY_SOURCE >= 2 will reject "%n" unless it's stored in read-only memory. And Ubuntu at least makes this a gcc default, so I wouldn't say nobody is doi
by hoytech 6y ago
Well, FORTIFY_SOURCE >= 2 will reject "%n" unless it's stored in read-only memory. And Ubuntu at least makes this a gcc default, so I wouldn't say nobody is doing anything against it:
$ cat tp.c
#include <stdio.h>
#include <string.h>
int main() {
char a[3];
printf(strcpy(a, "%n"));
return 0;
}
$ gcc -O3 tp.c ; ./a.out
*** %n in writable segment detected ***
Aborted (core dumped)
- saagarjha 6y agoDoes this work if you mprotect a read-only region writable?
- hoytech 6y agoIt uses the __readonly_area glibc function which actually parses /proc/self/maps: https://code.woboq.org/userspace/glibc/sysdeps/unix/sysv/linux/readonly-area.c.html#__readonly_area https://code.woboq.org/userspace/glibc/sysdeps/unix/sysv/lin... So no, I don't believe it will prevent using "%n" in memory that you have made writable. But this isn't really an issue because typically a format string exploit would have no way to arbitrarily call mprotect. That said, there are other ways to abuse format string bugs apart from %n, for example "Direct Parameter Access" to get stack cookies, and the like: https://cs155.stanford.edu/papers/formatstring-1.2.pdf https://cs155.stanford.edu/papers/formatstring-1.2.pdf