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->dev=open("/dev/sdb1");
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.

Continue reading Does aslr definitely end the possibility of code execution in the case of filesystems heap overflows?→