2 ms·

I recall once reading a bug-report thread of how null-check elisions caused a vulnerability in a big piece of software. I've tried to find it often, because it

by rocqua 7y ago

I recall once reading a bug-report thread of how null-check elisions caused a vulnerability in a big piece of software. I've tried to find it often, because it would be nice to reference in response to your kind of question. I'm afraid that more than an hour of searching hasn't turned anything up. I think it was a Firefox bug, but given my fruitless search, that seems suspect. Here's to hoping someone else happens to know what I am talking about and shares a link.

cpeterso 7y ago
It was a Linux bug: https://blog.regehr.org/archives/970 https://blog.regehr.org/archives/970
bdamm 7y ago
Not sure if this is "null-check elisions" but there was the famous case of the Debian SSH daemon package generating easily guessed keys because the packager "fixed" the upstream code... the upstream code was using uninitialized variables to seed randomness, and the packager's software flagged that as a bug, so it was patched by the packager. Of course, that's not a good way to seed randomness, so I think there's a real argument that the upstream code was, in fact, buggy.
- phaedrus 7y ago
  Kind of in the same vein, some code I was porting to a newer C++ compiler had "int error = get_status(x);" and I got a warning that the variable "error" is never used. So I commented the line out. After I finished fixing about 1,000 such warnings, re-running the program showed it no longer performed its serial I/O communication function. Turned out "get_status(x)" should have been called "send_data(x)". What was arguably the most important line out of 10,000 lines in the the project had nothing to differentiate it as special, and performs it's work as a "side effect" of setting a flag variable which is never checked.
krussell 7y ago
You might be thinking of this old linux kernel bug where a gcc optimization that deleted null pointer checks resulted in a vulnerability https://access.redhat.com/security/cve/CVE-2009-1897 https://access.redhat.com/security/cve/CVE-2009-1897 . There's a more interesting write up of the bug and patch at https://lwn.net/Articles/342330/ https://lwn.net/Articles/342330/ .

by rocqua 7y ago

cpeterso 7y ago

It was a Linux bug: https://blog.regehr.org/archives/970 https://blog.regehr.org/archives/970

bdamm 7y ago

Not sure if this is "null-check elisions" but there was the famous case of the Debian SSH daemon package generating easily guessed keys because the packager "fixed" the upstream code... the upstream code was using uninitialized variables to seed randomness, and the packager's software flagged that as a bug, so it was patched by the packager. Of course, that's not a good way to seed randomness, so I think there's a real argument that the upstream code was, in fact, buggy.

phaedrus 7y ago
Kind of in the same vein, some code I was porting to a newer C++ compiler had "int error = get_status(x);" and I got a warning that the variable "error" is never used. So I commented the line out. After I finished fixing about 1,000 such warnings, re-running the program showed it no longer performed its serial I/O communication function. Turned out "get_status(x)" should have been called "send_data(x)". What was arguably the most important line out of 10,000 lines in the the project had nothing to differentiate it as special, and performs it's work as a "side effect" of setting a flag variable which is never checked.

krussell 7y ago

You might be thinking of this old linux kernel bug where a gcc optimization that deleted null pointer checks resulted in a vulnerability https://access.redhat.com/security/cve/CVE-2009-1897 https://access.redhat.com/security/cve/CVE-2009-1897 . There's a more interesting write up of the bug and patch at https://lwn.net/Articles/342330/ https://lwn.net/Articles/342330/ .