It seems my comments in the April 30, 2021 The Verge story about the Linux kernel banning the University of Minnesota made some anonymous knucklehead mad enough to send me hate mail via my website. The author went to great pains to stay hidden. Congratulations. Nobody knows who you are. You win a cookie.
My web server logs tell the story.
196.240.54.119 - - [31/May/2021:08:18:37 -0500] "GET /contact/ HTTP/1.1" 200 141193 "https://www.dgregscott.com/contact/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.2 Safari/605.1.15"
196.240.54.119 - - [31/May/2021:08:25:19 -0500] "POST /contact/ HTTP/1.1" 200 138858 "https://www.dgregscott.com/contact/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.2 Safari/605.1.15"
Somebody accessed my contact form at 08:18:37, filled out the form, and submitted it 08:25:19. This generated the email above, which arrived in my inbox at 08:25:20. A whois lookup shows IP Address 196.240.54.119 belongs to an ISP in South Africa named FiberGrid. The IP Address itself is apparently in Latvia, and Scamalytics says it’s an anonymizing VPN.
It’s a shame this anonymous knucklehead took the cowardly approach.
What’s the fuss all about?
A few months ago, University of Minnesota researchers sent bogus patches to the Linux kernel development team, purposely introducing security vulnerabilities. After kernel developers evaluated the submissions, the researchers followed up with emails that the patches were bogus and then sent good patches.
The problem was, nobody told anyone on the kernel team about this experiment, and lots of kernel developers spent lots of time evaluating the bogus submissions, only to find out later the University used them as guinea-pigs. As with many open source projects, Linux kernel team members volunteer their time and don’t like somebody wasting it.
And then university researchers made it worse.
The researchers published their paper and then did it again – they submitted even more bogus patches. The kernel team said enough is enough, and after trading emails in the kernel.org email list, announced they would reject future submissions from the University of Minnesota until the university repairs its trust. The kernel team also poured time into reviewing past submissions for bugs in case somebody tried earlier experiments. That’s what happens when a community member violates its trust.
Apparently, my comment in The Verge story that offended this anonymous knucklehead was, “That paper, it’s just a lot of crap.”
Yep, I really did say that. I remember saying it. I probably also said something similar when Cory Hepola interviewed me about all this on WCCO Radio. And some anonymous knucklehead who wants to spew profanity won’t change my mind. Still, I should work on my diplomacy.
Why don’t I like this paper?
So, why don’t I like this paper? This is from page 4, starting in the last paragraph of the left column.
In general, the forming of vulnerabilities requires multiple conditions. When not all vulnerability conditions are present, the vulnerability is not formed yet. We call such a potential vulnerability as an immature vulnerability. Our study (see §VII-A) shows that OSS tends to have a large number of immature vulnerabilities, which poses hidden insecurity to OSS. First, immature vulnerabilities are not real vulnerabilities, so bug detectors (both static and dynamic ones) may not report them at all. Second, as will be shown in §III-A, OSS communities typically refuse to accept preventive patches for immature vulnerabilities. The Linux community explicitly state that they will not accept preventive patches [26]. Third, when the remaining conditions are introduced, due to the complexity of code (see §III-B) and other reasons, the newly introduced vulnerabilities often slip through the patch review, such as the example in Figure 1…
On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits, Qiushi Wu and Kangjie Lu, University of Minnesota
The concept of immature vulnerability is mostly hogwash. If somebody makes a small change to the code, it will introduce an exploitable vulnerability. Well, duh. If I take a couple shingles off my roof, rain will eventually ruin my house. Does that make shingles on roofs an immature vulnerability? But more important, what do we do about it? Just like shingled roofs, complex software systems have lots of inter-dependencies. A poorly thought out change in one spot might set up a problem in another spot.
Next, the authors take aim at the open source community by claiming open source software has a large number of these immature vulnerabilities. Well, maybe it does, maybe not. Compared to what? Does, say, Windows have a similar set of these so-called immature vulnerabilities? The paper offers no comparisons. I have a hunch *all* non-trivial software has spots where a small change could introduce big problems, just like shingled roofs around the world.
The paper also claims that newly introduced vulnerabilities often slip through the patch review. It’s hard to quantify “often,” but some patches do slip through the review process and introduce vulnerabilities. We all remember Heartbleed and others over the years. It’s also true the community fixes them quickly once discovered. I wish this paper offered an improvement instead of flagging what everyone in the community already knows – sometimes people make mistakes.
Other sections of the paper declare that C and C++ are insecure languages. But the paper doesn’t back it up with any data. How are they insecure? What does “insecure” even mean in this context anyway? And if these are insecure languages, what are secure languages?
Don’t be an anonymous knucklehead
Anyone who disagrees with my conclusions is welcome to comment. Tell me what you don’t like, tell me I’m nuts, make your argument, back it up with data. I might even offer you a guest blog post if you put something coherent together.
But don’t be an anonymous knucklehead.
Recent Comments