Linux kernel security fixes spotted before release with side channel attack on...developer mailing lists
- Reference: 1599248757
- News link: https://www.theregister.co.uk/2020/09/04/linux_kernel_flaws/
- Source link:
What's more, they have found that Linux kernel patches regularly get added in a way that bypasses public review and discussion, a practice that opens at least a theoretical risk of backdoored code.
In an ArXiv-distributed paper
[1]PDF
titled, "The Sound of Silence: Mining Security Vulnerabilities from Secret Integration Channels in Open-Source Projects," Ralf Ramsauer (University of Applied Sciences Regensburg), Lukas Bulwahn (BMW), Daniel Lohmann (University of Hanover), and Wolfgang Mauerer (University of Applied Sciences Regensburg/Siemens) outline a data mining scheme that amounts to a side channel attack on the open source vulnerability disclosure process.They describe the patch process to address the 2018 Level 1 Terminal Fault (L1TF) vulnerability, a side channel speculative execution attack that allowed data to be obtained from virtual machines on Intel-based servers.
"Unlike ordinary patches, these patches were—for obvious reasons—not discussed and developed on one of Linux’s public communication channels (i.e., mailing lists) beforehand," the paper says. "However, the fact that a patch was not publicly discussed betrays it: we will show that it is possible to detect such patches as soon as they enter a public repository."
The CVE entries for the L1TF flaw were filed in December 2017 and the vulnerability disclosure didn't happen until August 14, 2018, the paper explains. And Debian 9.2 didn't offer a patch until five days after that. So an attacker with foreknowledge of the flaw could have months to design and deploy exploit code.
Makes sense
What the German boffins have done is not that different from the process that led The Register on January 2, 2018, to spot the work being done [2]to patch Linux and Windows against the Spectre and Meltdown processor vulnerabilities prior to the planned disclosure date.
While we learned of the code repair work by recognizing from online chatter and [3]patch discussions suspiciously stripped of detail that something was amiss, the German researchers show that systematic data mining of public Linux mailing list messages and code commits may be even more effective at ferreting out undisclosed flaws.
We spent way too long on this Microsoft, Intel, Adobe, SAP, Red Hat Patch Tuesday article. Just click on it, pretend to read it, apply updates [4]READ MORE
In essence, gaps between Linux kernel code commits and the mailing list public discussions point to sensitive code patches that reveal security issues before they've been announced.
The boffins applied their technique to the seven month period prior to the release of Linux 5.4, released on November 24, 2019. "We find 29 commits that address 12 vulnerabilities," the paper says. "For these vulnerabilities, our approach provides a temporal advantage of 2 to 179 days to design exploits before public disclosure takes place, and fixes are rolled out."
The paper's authors contacted the commit authors to confirm that the changes addressed undisclosed flaws. And they note that they found patches for "an easy to exploit denial-of-service attack for ARM64-based Cavium systems" that took two months to be integrated into Ubuntu Bionic and remains unfixed in Debian Buster and the 4.19 Linux LTS tree.
Just can't commit
The research also touches on another issue of potential concern: code commits made without review or public discussion. Linus Torvalds, the authors say, made 40 such commits during the May-December 2019 research period, none of which had security implications.
And other trusted maintainers did too, mainly inconsequential stylistic fixes. Nonetheless, the possibility that untrustworthy code could get slipped into the Linux kernel through this process gap troubles the paper's authors.
"The existence of such channels, shows that trusted individuals can easily infiltrate the project, and secretly introduce malicious artifacts (while this possibility is given, our method allows for finding concrete instances, which is otherwise not possible)," the paper says. "The existence of such commits contradicts one of the key promises of an open development model."
The Register asked the Linux Foundation to comment. We've not heard back.
The boffins say in their paper that the Linux kernel community is aware of the issues they raised but has yet to settle on how to deal with them. They also observe that while their analysis focused on Linux kernel development, their technique can be generalized to other system-level open source projects like GCC, QEMU, U-Boot, LLVM, busybox, and others. ®
Get our [5]Tech Resources
[1] https://arxiv.org/pdf/2009.01694.pdf
[2] https://www.theregister.com/2018/01/02/intel_cpu_design_flaw/
[3] https://lkml.org/lkml/2017/12/4/709
[4] https://www.theregister.com/2020/08/11/patch_tuesday_august/
[5] https://whitepapers.theregister.com/
Re: Security by obscurity, yawn
For public evidence, I think this very site has the best example when they blew the lid on spectre early.
It clearly can and has happened.
Re: Security by obscurity, yawn
"What does security by obscurity offer?"
It can buy you a bit of time. The analysis demonstrates that, in this case, it may not buy much time.
Drama
"The existence of such articles, shows that trusted authors can easily infiltrate a paper, and secretly introduce malicious drama ..."
Fear mongering
I don't find the fear mongering about kernel maintainers credible. First, they are very few, highly trusted individuals. Second, the results of their activity is available for all to see after the fact. You don't need to see a log of every commit to notice a backdoor in source code, and I'm not even sure logs would be much help in that regard... it's all too easy to split such code across multiple commits, all of which look innocuous in isolation. The final output is by far the most important part to have available.
As for security patches... Maybe. That's a weird level of sophistication: Script-kiddie who puts in the effort to set-up major data mining and analysis to get an exploit that might be secret for a couple months. It should be fixable if ever exploited, with private branches of repos containing security-fixes, shared only between senior kernel devs and major distro maintainers.
Re: Fear mongering
"First, they are very few, highly trusted individuals. Second, the results of their activity is available for all to see after the fact."
A bit like Guy Burgess, Donald Maclean and co then?
We know that critical bugs can hide in plain view in open source software for years. I would be surprised if this attack vector has not been considered by actors who are prepared to take their time.
Linux is often touted as the most secure general OS, speed that fixes and patches are develope by unpaid developers doing it ffor the love, with public reviews of said code so anyone can pick holes. Implied is that all Linux distros are treated teh same
The reality is somewhat different, there is a backdoor for unreviewed code from a small number of developers, Patches are not always speedily developed and those that could be interested (nation state or larger criminal gangs) can ascertain details of known vulnerbilites due to the open source nature of teh patching process.
Also not all distributions are equal when it comes to patching, like mobile phone you may be at the mercy of the distro maintainer and the 3rd party that used that distro in their appliance to provide eth security fixes.
Its a wake up call that Linux is not just one thing, it is not secure, and it isa vastly more complicated thing to manage than many would lead you to believe. The days of Linux being and install and forget OS are long gone, its not up there with monthly patching but it presents a more complex problem for those sys admins that live on the front line and have to deal with reality of vast ranges of devices and OSes not just that one.
At work we have around 70 odd Linux servers and appliances running around 15 different flavours of Linux and no managemet tools to maintain them, these are all key things like security boxes, loadbalancers, network management etc. We have 700 windows boxes and one tool that manages the 3 flavours of OS beings used.
Your inability to manage your Linux estate does not mean it is unmanageable.
Security != Configuration Management
I'm a *nix head so I admit my bias, may colour my opinion.
Terraform / Ansible / PXE lets you image and provision.
The rest is testing, monitoring, and documenting the process for improving.
I can hire experts to pour over the source code, and make fixes for me. I can't do that for windows without serious cash, which makes it out of reach for a lot of firms.
Systems are complicated to manage properly but it's considerably more tractable a problem on Linux/*BSD kit.
The key things are the ability to nuke and pave, and relentless focus on improving cycle time.
Yes, real world systems require managing/securing and maintaining.
That's the profession, it's tractable on Linux, it's possible on Windows.
This is quite an interesting development. Basically, it means that an open source project team cannot guarantee that it is able to quietly fix security bugs without giving the game away that that's what they're doing. I suspect that as time passes this kind of data mining will only improve, to the point where it becomes difficult for work on criticial fixes to be carried out on public-facing repos without highlighting that a fix is underway.
The only way of hiding such work then is if there's also a closed source repo hidden away from the public eye. That raises all sorts of challenges, like who is allowed inside that private bubble, and is it breaking the license conditions by hiding it?
So What About Closed Source?
I wouldn't mind betting that closed souce projects have similar "tells". How about, what time of day does a key MS Windows software architect drive past on the way home? If they're burning the midnight oil, perhaps there's a reason.
A more elaborate take on that - if you know the network of people inside MS well enough and can see their behaviours in intimate detail (ahem, Google and Facebook), you might guess that, if the developers with associations to someone who talks about networks in Windows are all working late, Windows has a significant bug in that area that is not yet fixed.
And where that gets very interesting is if you consider who has such detailed access and data. Facebook, Apple, Google are the obvious ones.
So, how about TikTok, with their permissions-grab client apps?
The only way of truly defeating this kind of thing is if the "signal" is drowned out by deliberately generated "noise". So, perhaps whole teams get to work late simply for no other reason than to confuse the situation...
Security by obscurity, yawn
It's difficult to work out what this article is trying to tell us. If I understand it correctly there is a theoretical possibility that vulnerabilities can be determined by public traffic analysis. Is there any evidence it has happened? At least everyone knows the potential weaknesses.
What does security by obscurity offer?