Heap memory corruption in GitHub's Markdown table parsing extension
1–10 of 44 posts
Re: Heap memory corruption in GitHub's Markdown table parsing extension
#2Another integer overflow bites the dust.
Re: Heap memory corruption in GitHub's Markdown table parsing extension
#3I am a C++ fanatic---template metaprogramming is a beautiful thing---but I've come to believe that software that handles untrusted user input should never be written in C or C++. It's too difficult to write correct software by hand, memory safe languages are really the only way.
Re: Heap memory corruption in GitHub's Markdown table parsing extension
#4I am a C++ fanatic---template metaprogramming is a beautiful thing---but I've come to believe that software that handles untrusted user input should never be written in C or C++. It's too difficult to write correct software by hand, memory safe languages are really the only way.
Is this a vulnerability that would be impossible kn6, let's say, Rust?
Re: Heap memory corruption in GitHub's Markdown table parsing extension
#5This seems like a good opportunity to use wasm on the server to sandbox the processing of user provided content. Of course they could also try rewriting in a safer language, but given that this already exists and handles all their content, wasm might be a simple defense in depth protection.
Re: Heap memory corruption in GitHub's Markdown table parsing extension
#6I am a C++ fanatic---template metaprogramming is a beautiful thing---but I've come to believe that software that handles untrusted user input should never be written in C or C++. It's too difficult to write correct software by hand, memory safe languages are really the only way.
Is this a vulnerability that would be impossible kn6, let's say, Rust?
This seems to be the patch: https://github.com/github/cmark-gfm/commit/cf7577d2f74289cb8...
Integer overflow can happen in Rust, but it's well-defined, not undefined. This helps.
Bounds checking is part of indexing, and so even if an index overflows, the check should happen, and panic.
"impossible" is a strong word, but it would be significantly less likely in Rust. If you did the same thing as you did in C, with unsafe, then it could happen. But there's not a lot of reason to 99.9999% of the time, as it's the more difficult and less ergonomic option.
Re: Heap memory corruption in GitHub's Markdown table parsing extension
#7I am a C++ fanatic---template metaprogramming is a beautiful thing---but I've come to believe that software that handles untrusted user input should never be written in C or C++. It's too difficult to write correct software by hand, memory safe languages are really the only way.
Does there actually exist any practical way to ensure user input does not cause mischief when authoring C/C++ programs at scale? Are memory-safe languages the only answer?
Re: Heap memory corruption in GitHub's Markdown table parsing extension
#8I am a C++ fanatic---template metaprogramming is a beautiful thing---but I've come to believe that software that handles untrusted user input should never be written in C or C++. It's too difficult to write correct software by hand, memory safe languages are really the only way.
Is this a vulnerability that would be impossible kn6, let's say, Rust?
Yes. Heap Memory Corruption is a type of memory safety issue that's impossible in Safe Rust. (As usual, this depends on any unsafe code and the compiler being bug-free, but that's supposed to be much easier to prove since the "scope" of things to check for correctness is much reduced).
Re: Heap memory corruption in GitHub's Markdown table parsing extension
#9Earlier quoted context omitted.
Is this a vulnerability that would be impossible kn6, let's say, Rust?
This seems to be the patch: https://github.com/github/cmark-gfm/commit/cf7577d2f74289cb8... Integer overflow can happen in Rust, but it's well-defined, not undefined. This helps. Bounds checking is part of indexing, and so even if an index overflows, the check should happen, and panic. "impossible" is a strong word, but it would be significantly less likely in Rust. If you did the same thing as you did in C, with uns…
the actual commit fix has some comments that may be useful for understanding:
https://github.com/github/cmark-gfm/commit/ac80f7b56522ffa15...
Re: Heap memory corruption in GitHub's Markdown table parsing extension
#10I am a C++ fanatic---template metaprogramming is a beautiful thing---but I've come to believe that software that handles untrusted user input should never be written in C or C++. It's too difficult to write correct software by hand, memory safe languages are really the only way.
Does there actually exist any practical way to ensure user input does not cause mischief when authoring C/C++ programs at scale? Are memory-safe languages the only answer?
Yes, the security standards like MISRA and AUTOSAR basically castrate C and C++ into subsets similar to those languages.