Local only Filesystems (like ntfs or btrfs) consists of many data structures that require very complex code for parsing them.
So, such filesystems if implemented in user space can suffer of buffer overflows vulnerabilities like many parser.

In that case, the attacker leaves a high capacity sd card with crafted data on the car park that will take control of the staff member’s laptop as soon it tries to mount it.

The point is I think there’s nothing to fear from using 512 Gb sd card found on the ground anymore because of aslr :

  • The only way I know to bypass aslr on 64 bits Linux is to exploit the repeated network accesses normally done by the executable (which allows the attacker to select the correct return address to send inside their exploit).
  • Today’s major Linux distributions like Red Hat and Chrome os or android now compile and link all their executables with -fPIE, so user space programs never uses any static address anymore.
  • filesystems implemented with fuse that only deal with device files don’t contain any code that access networking. Moreover, after searching for previous vulnerabilities in user space filesystems I didn’t find any exploit that bypass aslr. The only working filesystems exploits I found works from kernel code or rely on the main executable not being address independent. (though I might searched badly and a contre example might exists)

Question :

So as long as the filesystem isn’t nfs or serial attached scsi and does not run in kernel space nor the system contains position dependent executables, nor use executable stack, aslr does not only mitigates, but it completely prevents buffer overflows attacks, isn’t it ?
Or can alsr be bypassed by performing a single buffer overflow that takes control of all variable allocated on heap even if the program doesn’t uses any networking ? (I also noticed with fileystem that the whole heap strucure can be made predictable)

Details :

In the case of filesystems, the typical thing that happen is this :

struct boot_sector ef=malloc(sizeof(struct boot_sector));
ef->sb=malloc(sizeof(struct super_block));
pread(ef->dev, ef->sb, sizeof(struct super_block), 0);
ef->first_extend =malloc (user_controlled_value * CLUSTER_SIZE); // get allocated at the begging of the heap.
pread(ef->dev, ef->first_extend, second_controlled_value << CLUSTER_SIZE, 1024); // overwrite every struct * that follow, including ef. Notice since we control file system data we know the value the varying struct * should have.

Though in that kind of case, no structures hold pointer information, thus requiring to corrupt glibc’s dlmalloc data.

  • Of course, I know buffer overflows that corrupt glibc’s dlmalloc data structures aren’t the only to get remote code execution. In the current case, I only care about code execution, not thing like crash or infinite loops. In the reverse, it means it’s not required to fix or investigate hypothetical buffer overflow in fuse file systems since they aren’t exploitable outside debian or ubuntu. – user2284570 Mar 19 '17 at 21:55
  • @paj28 : it relies on having some executables files compiled with position dependent code. something that will never happen on chrome os for ntfs-3g or exfat-fuse or sustemd-udevd. though there is partial scripting available : the user trying to mount the device several times by clicking on the drive inside the file explorer (which makes try the exploit on different addresses). – user2284570 Mar 19 '17 at 22:14
  • 1
    That exploit doesn't depend on having some non-PIE files; it is a "true" ASLR bypass. If a file system driver had a similar buffer overrun flaw, someone could construct a similar exploit and ASLR would not stop them. – paj28 Mar 19 '17 at 22:19
  • 1
    @forest nevermind. The answer to the question is yes because I sucessfully found a way to trigger a glibc segmentation fault and get paid by Google for the bug report. – user2284570 Nov 18 '18 at 11:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.