How do you fix a problem like open-source security? Google has an idea tho constraints may not go down well
- Reference: 1612467173
- News link: https://www.theregister.co.uk/2021/02/04/google_open_source_security/
- Source link:
The security of open-source software is critical because of its wide adoption, from the Linux kernel on which most of the internet runs to little JavaScript libraries that get built into millions of web applications, sometimes via a chain of dependencies somewhat hidden from the developer. Vulnerabilities such as one [1]discovered recently in the essential sudo utility affect millions of systems.
[2]
A team from Google has now [3]posted at length about the issue in the hope of "sparking industry-wide discussion and progress on the security of open source software."
The post – called "Know, Prevent, Fix" – is co-authored by Eric Brewer, VP of infrastructure at Google, distinguished engineer Rob Pike (co-designer of the Go language); principal software engineer Abhishek Arya; program manager, Open Source Security, Anne Bertucio; and product manager Kim Lewandowski.
[4]
Decade-old bug in Linux world's sudo can be abused by any logged-in user to gain root privileges [5]READ MORE
Separately, Google is a founding member of the Linux Foundation's [6]OpenSSF (Open Source Security Foundation), along with many others including GitHub, GitLab, Intel, IBM, Microsoft, NCC Group, OWASP, Red Hat and VMware.
The new post references some of the work of OpenSSF, in particular [7]Security Scorecards , which is an automated tool to assess the security of a project according to various criteria such as use of code review, static analysis, tests, and the existence of a security policy.
Google suggested that "open source software should be less risky on the security front, as all of the code and dependencies are in the open and available for inspection and verification," but noted that this only applies if people are "actually looking."
The dependency issues mean thousands of packages are in use, making it hard understand its security. "We must focus on making fundamental changes to address the majority of vulnerabilities," the team insisted.
Google, it turns out, does not entirely trust the usual open-source repositories and package managers. The company keeps "a private repo of all open source packages we use internally – and it is still challenging to track all of the updates," we are told.
It is looking for better tools to automate this. The paper appears to be in part based on the company's own internal practices, recognising that without cooperation across the software industry these standards would be beyond the means of most organisations.
The company's proposal includes some specifics, noting that some of the ideas are intended only for open-source software categorised as critical:
A standard schema for vulnerability databases. This would make automation easier as a tool could better understand data across the industry.
A notification system for the actual discovery of vulnerabilities.
That no changes are made to critical open-source software without code review and approval by two independent parties.
That owners and maintainers of critical software projects are not anonymous but have verified identities, either public or via a trusted entity, and use strong authentication such as 2FA. The ream proposes developing a federated model for identities.
For critical software, tamper-checking for software packages and artefacts, such as Google itself proposed with [8]Trillian .
For critical software, an attested build system, perhaps with trusted agents that provide a build service and sign the compiled packages.
The Google team acknowledged that its goals for critical software are "more onerous and therefore will meet some resistance, but we believe the extra constraints are fundamental for security."
Good luck with that, Google
While Google's proposals are a logical outcome of thinking through the hows and whys of software vulnerabilities, it does seem far removed from the norms of open-source culture. Could the standards proposed be imposed on open-source projects without making them slower and more bureaucratic, and alienating some of the highly motivated individuals who make them work?
Rubbish software security patches responsible for a quarter of zero-days last year [9]READ MORE
"Try telling the leaders of various projects like libpng, libjpeg-turbo, openssl, ffmpeg etc that they are not allowed to make 'unilateral' changes to their own projects just because they are critical software in the FOSS world," said [10]one comment on the proposals.
It also seems odd in some ways that Google chose to post this proposal on its own open-source blog, rather than hammering out a collaborative paper in the context of OpenSSF, which is a more neutral environment, though this of course may follow.
Google's proposals seem more stringent than the ideas presented in the OpenSSF [11]technical vision last week, which are more focused on making it easier for developers to write secure code. Although in the light of the SolarWinds attack, in which a compromised build environment was used to insert malicious code, the Linux Foundation's director of open source supply chain security, David Wheeler, posted about [12]hardening build environments , echoing some of Google's concerns.
[13]
The question is not only how use of open source affects security, but how the requirements of security will impact open source. ®
Get our [14]Tech Resources
[1] https://www.theregister.com/2021/01/26/qualys_sudo_bug/
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YBx8iKzHOlAYvrMuQXfwSgAAABg&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://opensource.googleblog.com/2021/02/know-prevent-fix-framework-for-shifting-discussion-around-vulnerabilities-in-open-source.html
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YBx8iKzHOlAYvrMuQXfwSgAAABg&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://www.theregister.com/2021/01/26/qualys_sudo_bug/
[6] https://www.theregister.com/2020/08/03/linux_foundation_forms_openssf/
[7] https://github.com/ossf/scorecard
[8] https://transparency.dev/application/add-tamper-checking-to-a-package-manager/
[9] https://www.theregister.com/2021/02/03/enigma_patch_zero/
[10] https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1236209-google-proposes-know-prevent-fix-framework-for-dealing-with-security-vulnerabilities?p=1236280#post1236280
[11] https://openssf.org/blog/2021/01/28/jan_2021_announcement/
[12] https://www.linuxfoundation.org/en/blog/preventing-supply-chain-attacks-like-solarwinds/
[13] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YBx8iKzHOlAYvrMuQXfwSgAAABg&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[14] https://whitepapers.theregister.com/
Lots of questions
* What is a "vulnerability database" and why do we need multiple ones? What's the difference between this and the list of vulnerabilities that CERT maintains?
* "A notification system for the actual discovery of vulnerabilities." - WTF? Isn't that CERT?
* "That no changes are made to critical open-source software" - who determines "critical software"?
* "an attested build system" means "a Google build system" right?
Re: Lots of questions
"an attested build system" means "a Google build system" right?
If you ever had the sad misfortune to be unable to avoid using GNU Radio you would be pleased if the code would actually build out of the repository. A project that needs to invent its own build management tools is a sh*t-show in the making,
Re: Lots of questions
Excellent point, which is why complex build systems can be a problem. One that's there for convenience, automating the process of test, package, sign, and release is fine. One where the build system is intrinsically connected to the build such that you can't easily build without it is bad. Unfortunately, I have seen build systems like that more often than I'd like.
Inevitably ...
some people are starting to think that they 'own' GNU/Linux, because ownership is what they are all about.
The day may indeed come when 'Linux', as a software stack, effectively becomes a corporate product, but the thing they cannot own is the philosophy that drives 'FLOSS'. If the corporate ossification and monetisation of 'Linux' does ensue the spirit driving 'FLOSS' will simply move elsewhere.
There will always be a place for a wild IT frontier where people with an itch to scratch and a generosity of spirit to share their solution will set it free to be picked up by whoever wants to take it and develop it to scratch their particular itch.
Re: Inevitably ...
Thing is, we already have "corporate Linux" in the form of distros by Red hat, Canonical, etc. They are the ones who should be doing the code review and build verification before it becomes "mainstream" to paying customers.
Customers who expect that without paying have an interesting prespective on the world.
Re: Inevitably ...
The problem is the friction between those who think GNU/Linux is 'just a free version of Windows' and those who think that 'GNU/Linux' is a manifestation of a particular philosophy of 'freedom'.
One of the 'costs' of that freedom is that people walk away from stuff they aren't interested in - even if it really matters to others or themselves. Tough on everyone, but that's the reality. Sure someone can pay to have the work done, but if they aren't prepared to share why are they even in the room? There are perfectly good proprietary systems available just down the corridor where 'ownership' is the name of the game, and they can screw over everyone else as much as they like.
Re: Inevitably ...
Aye, look at the titles of those proposing this:
VP of infrastructure
distinguished engineer
principal software engineer
program manager
product manager
Looks like an empire in the making complete with bureaucratic tendencies.
The suits are moving in and will take a lot of shifting.
Still this is FLOSS we are talking about and they may have bitten off more than they can chew
You want all this, Google
If you want all of these things, how about you do them. And no, that does not mean you give free Google Cloud credits to the projects. It means you construct any standard protocols you want and work to get them adopted. And when people don't adopt them because they're arcane and ill-supported by anyone but you, you change them so they do what you and others want. And you support and secure any new databases or systems you think people need. If they're so great, you can expect that others will adopt them voluntarily and continue to support and advance them. If you construct them to lock in developers, expect to be snubbed.
Free software developers work because they see a need and they're generous people. They don't work to keep your salary coming in, and they're not going to change everything because you don't like what they're doing now. Don't try to force anything on them unless you want them to hate you. You want to improve things, do the work.
Re: You want all this, Google
The downside of that is that this is Google. The Google that simply dumps any plaything it gets tired of.
Re: You want all this, Google
The Google that simply dumps any plaything it gets tired of.
I don't think Google is likely to tire of dealing with security. They may eventually give up because the problem is too intractable. But security of the common computing/communications structure is pretty central to Google's business model. No security on the internet means not much cloud and eventually severely restricted digital advertising and a reduced bottom line. If there is anything Google cares about, it is its bottom line.
Turn about's fair play.
"Google, it turns out, does not entirely trust the usual open-source repositories and package managers."
On the other hand, show me a FOSS aficionado who trusts go-ogle-abet with ... well, with anything at all.
"Try telling the leaders of various projects like libpng, libjpeg-turbo, openssl, ffmpeg etc that they are not allowed to make 'unilateral' changes to their own projects just because they are critical software in the FOSS world,"
Worse, try telling them that they are not allowed to make changes to their own FOSS project because Alphabet is worried about go ogle's bottom line.
I'm looking forward to an open source license that states something along the lines of "Free for anyone, anywhere, to use for anything ... except by Alphabet, its subsidiaries (e.g. go ogle, et alia), it's officers and employees and anything that comes into financial contact with them in perpetuity". Dunno how it would hold up in court, but it would make me giggle ... and might, just might, get the point across.
factors like verified identity, code review, and trusted builds
You don't need to verify the identity of the person who did the change when you can look at exactly what was changed. Especially when you're a company that knows so much about everyone anyway, and would probably start flagging up contributions if that person failed one of your secret checks linked to your own database for any reason, however minor.
If you don't trust the code, you're free to review it (and if the project has many contributors, you know lots of eyes already have).
If you don't trust the build, build it yourself.
Problem solved. Exactly how it was intended to be.
Hmm, so they want OSS projects to behave like paid projects, but without actually paying them?
Goals may be noble, but really having some cash thrown towards critical projects would be a good thing as well. Before they cause a problem and emergency work starts like openssl...