I’ve been auditing a class of bugs using the following methodology.
- Find instances of malloc, if the malloc size is fixed, then discard.
- Then follow the code backwards to determine if it comes from a user controlled location (but don’t get carried away with following the code unless the next condition is met).
- If the size is user controlled, or if the code flow is hard to follow, see if the malloc size uses an arithmetic operation like foo + user_len, or foo*user_len. This could potentially be an integer overflows.
- Verify that there is no input validation that restricts the size, and make sure its user controlled.
It’s a bit easier in practice to audit for these types of bugs. It seems like it could lend itself to automatic bug checking.. I curse myself for not having the fortune of being able to write on (maybe more on this later). But there are still many bugs to be found using this simple approach of auditing.
I started looking for Linux bugs, thinking that there might be potentially be kmalloc integer overflows in the drivers concerning IO and Ioctl calls.
I did find a couple bugs fairly quickly, but another problem presented itself. The times I saw instance of this bug, the kmalloc call was quickly proceeded by a copy_from_user call. But due to the nature of those integer overflows, the size parameter being used in the copy_from_user call is very large. And Linux verifies that the resulting buffers would reside in the appropriate text or data segment.
There are probably more instances of this type of bug that dont encounter the copy_from_user call immediately blocking exploitation. I will have to continue auditing to see if any more bugs appear.