![]() ![]() While it’s not an apples to apples comparison, I find table 3 in the paper interesting. I suspect it would paint a very similar picture though. Unfortunately I don’t think it could be done legally without the company’s permission, and it’s doubtful a company would authorize the publication of such research. It would have been even more interesting to see the exact same research conducted into proprietary software companies as well for the sake of comparison. We don’t have data on how many of those commits were “hypocrite commits” as the paper puts it, but when it comes to the attack surface it doesn’t really matter so much why a vulnerability is there, just that it is.Įven though the community has understandably condemned them, I do find the research to be quite insightful. The CVE incidents are proof that vulnerabilities can and do make it into the kernel. This paper confirms what many engineers already know, linux is not impervious to such problems. These systems are very complex, and for better or worse they’re written in a language, C in particular, that is notorious for these vulnerabilities. Where did you get 80% from? I didn’t see that in the paper.Īs outsiders, we want (and sometimes naively expect) our operating systems to be invulnerable, but as engineers working these systems we know that’s not the case. Had they been real attackers I very much doubt they would’ve been caught at all. Worse it looks like the researchers were only caught because they were pushing too hard to gather stats, actively trying to prevent their attempts from being merged, and published a paper describing what they’re doing and why. Their research confirms what I’ve suspected for ages – a “semi-anonymous” malicious contributor can inject vulnerabilities into high profile open source projects (Linux) with a very high success rate (up to 80% success in some cases), and retry if their attempt/s are detected until they succeed. This is obviously the only correct course of action, and the swift response by the university is the right one. If you wish to do work like this, I suggest you find a different community to run your experiments on, you are not welcome here.īecause of this, I will now have to ban all future contributions from your University and rip out your previous contributions, as they were obviously submitted in bad-faith with the intent to cause problems. Our community does not appreciate being experimented on, and being “tested” by submitting known patches that are either do nothing on purpose, or introduce bugs on purpose. ![]() So what am I supposed to think here, other than that you and your group are continuing to experiment on the kernel community developers by sending such nonsense patches? They obviously were _NOT_ created by a static analysis tool that is of any intelligence, as they all are the result of totally different patterns, and all of which are obviously not even fixing anything at all. Now you submit a new series of obviously-incorrect patches again, so what am I supposed to think of such a thing? You, and your group, have publicly admitted to sending known-buggy patches to see how the kernel community would react to them, and published a paper based on that work. Replying to the researcher in question, Kroah-Hartman wrote: This was, of course, discovered, and kernel maintainer Greg Kroah-Hartman immediately banned the entire university from submitting any code to the Linux kernel. It turns out researchers from the University of Minnesota were intentionally trying to introduce vulnerabilities into the Linux kernel as part of some research study. We will report our findings back to the community as soon as practical. We will investigate the research method and the process by which this research method was approved, determine appropriate remedial action, and safeguard against future issues, if needed. ![]() We have immediately suspended this line of research. We take this situation extremely seriously. The research method used raised serious concerns in the Linux Kernel community and, as of today, this has resulted in the University being banned from contributing to the Linux Kernel. Leadership in the University of Minnesota Department of Computer Science & Engineering learned today about the details of research being conducted by one of its faculty members and graduate students into the security of the Linux Kernel. A statement from the University of Minnesota Department of Computer Science & Engineering: ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |