Category Archives: ASLR

Google Patches Critical ‘Broadpwn’ Bug in July Security Update

Posted on by

The July Android Security Bulletin patches 11 critical remote-code execution bugs including one dubbed ‘Broadpwn’ that impacts both Android and iOS devices. Continue reading Google Patches Critical ‘Broadpwn’ Bug in July Security Update→

Trouble building a ROP chain

Posted on by

I am trying to exploit a small program. The program looks somewhat like this:

int func(void) {
    char text[100];
    scanf("%s", text);
    return 0;
}


int foo(unsigned short rand) {
    char RandomBuffer[rand];
    return func();
}


int main(int argc, char* args[]) {
srand(time(NULL));
    return foo(rand() % 1000);
}

I used ROPgadget to build a ROP chain. The tool finds a gadet which is needed for the attack:

 Gadget found: 0x8058fcc pop edx ; ret

My ROP chain starts like this:

p = ‘rnd padding’
p += pack('<I', 0x08058fcc) # pop edx ; ret

However when executing my exploit I get:

Stopped reason: SIGILL
0x08058fcc in _int_memalign ()

The EIP points to the address computed by ROPgadget but somehow it is not the correct command.

EIP: 0x8058fcc (<_int_memalign+108>:    lock mov eax,esi)

What am I missing?

Cheers

Continue reading Trouble building a ROP chain→

Security Analyst Summit 2017 Day One Recap

Posted on by

Mike Mimoso and Chris Brook recap the first day of this year’s Security Analyst Summit, including Mark Dowd’s memory corruption bug keynote, the digital archeology around Moonlight Maze, ATM hacking, and the Lazarus APT. Continue reading Security Analyst Summit 2017 Day One Recap→

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

Posted on by

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?→