3 ms·
How about this in stdlib.h: void *malloc(signed long long int untrusted_size) { size_t size; if (untrusted_size < 0) { fprintf(stderr,
by jancsika 7y ago
How about this in stdlib.h:
void *malloc(signed long long int untrusted_size) {
size_t size;
if (untrusted_size < 0) {
fprintf(stderr, "warning: exploit "
"detected. Click <ok> to cancel");
}
size = (size_t)untrusted_size;
etc.
}
Or better yet redefine malloc with a wrapper and include the __line__ and __file__ in the exploit error.
Edit: markdown
- saagarjha 7y agoThis might be what you want, from glibc: https://sourceware.org/bugzilla/show_bug.cgi?id=23741 https://sourceware.org/bugzilla/show_bug.cgi?id=23741
- pornel 7y agoThe hack depends on numeric overflow in the caller that flips negative number into positive, so malloc can't possibly know it got the wrong size. It's even funnier that signed overflow is Undefined Behavior in C, so the compiler is allowed to assume it can never happen (and thus let it happen, and even remove non-kosher overflow checks).
- jancsika 7y ago> The hack depends on numeric overflow in the caller that flips negative number into positive, so malloc can't possibly know it got the wrong size. Look again at the hack-- Ted is sending a negative number to malloc. If I change malloc's interface to accept signed numbers, then I can check inside the definition for negative numbers and report to the user that something bad has happened.
- verall 7y agoMaking malloc take a long long on 32b archs is a _real_ perf hit. At least make it an ssize_t.