Conversation

1) it’s impressive this was done before the patch was even out — proving again that silent fixes can easily be discovered 2) bugs like these (integer overflows!!), in one of the most exposed kernel drivers out there, continue to make me doubt how much code review/analysis happens

Quote Tweet

Synacktiv

@Synacktiv

Mar 12, 2020

Since MSRC just published a fix for CVE-2020-0796, here's @_lucas_georges_ quick and dirty root cause analysis on it: synacktiv.com/posts/exploit/ #sambadijaneiro

114

This Tweet was deleted by the Tweet author. Learn more

Replying to

and

Realistically, programmers won't thoroughly verify that every integer operation with the potential to overflow does not overflow. Even if they tried, they may make bad assumptions or mistakes. If you want to catch it reliably, checked overflow needs to be an implicit default.

Replying to

and

Expecting people to do that at scale is out of touch. Humans are not capable of completely avoiding mistakes. Blaming programmers for flaws in tools isn't going to fix the problems. Systemic issues are best solved with a systemic fix, not an expectation of avoiding human errors.

Replying to

and

True, but using safe integer functions here and there could help. At least where values can be controlled by external input. I mean, they do that a lot afterwards during patching, so they could have done it in the first place as well. :)

Replying to

and

The issue is not a lack of good ways to perform overflow checks. Integer arithmetic is everywhere and unchecked overflow is the default in C and C++. Realistically, developers are not going to carefully check and document why each unchecked arithmetic operation cannot overflow.

Replying to

Developers are going to continue making these errors, and the tooling does not give them a way to realistically avoid all of these issues even when taking great care. When the default behavior of something so pervasive is unsafe, it will never be surprising that it goes wrong.

5:43 PM · Mar 13, 2020Twitter Web App

Replying to

and

Yes we agree that the problem is not lack of safe ways to do things. That's given in this context. It's either lack of time to actually comply with them, or 'just cause...'. That was my point actually.

Replying to

and

Developers that are taking great care, carefully reviewing code and having it audited still end up having a steady stream of integer overflow and memory corruption bugs when the language of choice is one where those are pervasive issues encouraged and obscured by language design.