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

Interesting topic. Why not submit a patch to allow the {fast checks, print error, do not abort} use-case?



I've had little success with that in the past -- I've submitted patches for both valgrind and AddressSanitizer which have gone nowhere. (For the record these are https://bugs.kde.org/show_bug.cgi?id=393926 and https://reviews.llvm.org/D46546 -- feel free to upvote them!)

I suspect the same would happen with glibc. To be fair, the maintainers for these packages have a lot on their plates, and tend to pay more attention to submitters who they see often, so one-shots like these just don't bubble up to the top.


Speaking as someone who exploits programs for fun...that would not be a good idea at all. Not aborting in the face of _obvious_ memory corruption means continuing onwards with the memory in some weird state which could cause much more serious problems later on. And, it makes an attacker’s job a lot easier if they don’t have to worry about triggering malloc’s checks while gradually corrupting your heap and taking control of the program through a memory error.


There are already options that don't abort anyways, unfortunately.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

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

Search: