Hacker News new | past | comments | ask | show | jobs | submit login

> I don't understand how people are overflowing 32 and 64 bit integers

Some tame examples:

- When retrofitting >4GB file support into an existing program.

- Counting in milliseconds (e.g. GetTickCount overflows every ~50 days - if that causes you a crash, it will be a very nasty rare bug, to the point where windows checked builds actually advance that time by ~49 days to make it repro faster: https://msdn.microsoft.com/en-us/library/windows/desktop/ms7... .)

A less tame example:

- Any deserialization that involves untrusted sources. (So, all deserialization - there's a reason your IT department doesn't want you opening random PDFs!)

Say you have an array. So you allocate "sizeof(Element) * elements" bytes. Attacker picks "elements" such that this overflows to a small/near-zero value - which successfully allocates - does a similar amount of IO, which also succeeds - then tries to loop over "elements" number of array elements, which didn't overflow without the multiply, and is now reading uninitialized memory.

At minimum this is a potential denial of service attack (just read until you hit an unmapped page.)

But it's easy to see how this could be (ab)used for data exfiltration as well in a typical C codebase. Say this is a simple echo or chat server - it's going to write whatever it reads to someone, and won't stop until it crashes (if it crashes). That uninitialized memory might be private messages to other users... or it might be database credentials, or worse.

And this chat server probably copies that data it read around - so now you've got potential buffer overflows writing data. In the old days, you could use this to stomp x86 instructions with your own - pwned! Nowadays you have to use slightly more complicated techniques like ROP chains and figuring out ways to defeat ASLR - but the fundamental potential is still there.

It's worth noting that panicing doesn't actually fix the potential denial of service attack. But it probably makes it easier to figure out what's going on when fuzzing for such problems, makes unintentional overflows clearly bugs to be fixed rather than "eh whatever's" to be ignored, and helps prevent the more serious variations on that attack.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: