Difference between revisions of "Open Source Security"

From MgmtWiki
Jump to: navigation, search
(Problem)
(Problems)
(One intermediate revision by the same user not shown)
Line 16: Line 16:
 
# Shortening the response time for distributing and implementing fixes, which is a challenge since no one knows where the defective code is being used.
 
# Shortening the response time for distributing and implementing fixes, which is a challenge since no one knows where the defective code is being used.
  
==Problem==
+
==Problems==
 
Security problems can be created at development time and at production time. Both are considered here.
 
Security problems can be created at development time and at production time. Both are considered here.
 
* When the code is open sourced, any attacker can look deeply for bugs that other have not discovered.
 
* When the code is open sourced, any attacker can look deeply for bugs that other have not discovered.
* Must of the code that s created in the Open Source community is built with open source tools and libraries that may not have high security ratings.
+
* Must of the code that s created in the Open-Source community is built with open-source tools and libraries that may not have high security ratings.
* Dev tools like gcc or even Powershell installed on production computers can make life easy for attackers. When dev tools are installed they typically come with many support tools that also help attackers.
+
* Dev tools like GCC or even PowerShell installed on production computers can make life easy for attackers. When dev tools are installed, they typically come with many support tools that also help attackers.
* [https://www.synopsys.com/software-integrity/resources/analyst-reports/open-source-security-risk-analysis.html Open source User and Risk Analysis Report] published annually by Synopsys shows that in 2020 there were 528 open-source components per App. And that 84% of OSS codebases carried some vulnerability. The more an industry depended on high-growth and OSS, the more likely they were to having vulnerabilities in their applications.
+
* [https://www.synopsys.com/software-integrity/resources/analyst-reports/open-source-security-risk-analysis.html Open-source User and Risk Analysis Report] published annually by Synopsys shows that in 2020 there were 528 open-source components per App. And that 84% of OSS codebases carried some vulnerability. The more an industry depended on high-growth and OSS, the more likely they were to having vulnerabilities in their applications.
* The "[https://www.wired.com/story/lo4j-ftc-vulnerability/ The FTC Wants Companies to Find Log4j Fast. It Won't Be Easy]" article it is clear that no one really knows the full extent of their exposure to vulnerabilities in open-source code.
+
* The "[https://www.wired.com/story/lo4j-ftc-vulnerability/ The FTC Wants Companies to Find Log4j Fast. It Won't Be Easy]" article makes it clear that no one really knows the full extent of their exposure to vulnerabilities in open-source code.
  
 
==Development Solutions==
 
==Development Solutions==

Revision as of 14:44, 23 January 2022

Full Title or Meme

Open Source Security technically applies to all software where the source code is available. In practice it typically means software that is developed using open source libraries and tools.

Context

  • A common problem with code that was developed in closed, even secretive, environments was often buggy and of unknown quality.
  • In fact code like OpenSSL had bugs that persisted for years before they were discovered and patched.
  • An effort by the University of Minnesota has shown that a determined long-term effort could subvert the entire Linux security model. 2021-07-18

Executive Order

The White House Executive Order on Cybersecurity (2021-05-12)has its own wiki page.

  • It focused and several areas that had relevance to OSS.
    • Software Bill of Materials, which come is almost no OSS today. Developers are used to downloading modules on-the-fly and expect that to be a feature not a bug.
    • Requirement that all companies selling the the US Government use secure software development practices which are notably absent in thee OSS hacker culture.
  • The was a White House Meeting with OSS community on 2022-01-13. The discussion focused on three topics:
  1. Preventing security defects and vulnerabilities, which is a challenge for developers who are not paid for their work.
  2. Improving the process for finding and fixing defects, which the participatants thought should focus on the most used code, rather the the code that was shipped to the US government (odd!)
  3. Shortening the response time for distributing and implementing fixes, which is a challenge since no one knows where the defective code is being used.

Problems

Security problems can be created at development time and at production time. Both are considered here.

  • When the code is open sourced, any attacker can look deeply for bugs that other have not discovered.
  • Must of the code that s created in the Open-Source community is built with open-source tools and libraries that may not have high security ratings.
  • Dev tools like GCC or even PowerShell installed on production computers can make life easy for attackers. When dev tools are installed, they typically come with many support tools that also help attackers.
  • Open-source User and Risk Analysis Report published annually by Synopsys shows that in 2020 there were 528 open-source components per App. And that 84% of OSS codebases carried some vulnerability. The more an industry depended on high-growth and OSS, the more likely they were to having vulnerabilities in their applications.
  • The "The FTC Wants Companies to Find Log4j Fast. It Won't Be Easy" article makes it clear that no one really knows the full extent of their exposure to vulnerabilities in open-source code.

Development Solutions

The Supply Chain must be fully documented so that software builds and audits can both succeed in improving security of the software packing to be delivered to the production machine.

  • Make itself is fine. make is merely a dependency tracking and automation framework. It is typically used in conjunction with compilers, though, and those preferrably should not be available on a production system, as they're completely un-necessary. The same holds true for all un-needed packages, whether those be shared libraries, interpreters, etc.

Production Solutions

Configuration of Solution

Configuration of Server

Some people will argue that the presence of development tools on a production machine will make life easier for an attacker. This however is such a tiny roadbump to an attacker, that any other argument you can find for or against installing the development tools will weigh more.

If an attacker was able to penetrate the system so far, that they could invoke whatever tools are present on the server, then you already have a serious security breach. Without development tools there are many other ways to write binary data to a file and then run a chmod on that file. An attacker wanting to use a custom build executable on the system at this point could just as well build that on their own machine and transfer it to the server.

There are other much more relevant things to look out for. If an installed piece of software contains a security bug, there is a few ways it could be exposed to an attacker:

  • The package could contain a suid or sgid executable.
  • The package could be starting services on the system.
  • The package could install scripts that are invoked automatically under certain circumstances (this includes cron jobs, but scripts could be invoked by other events for example when the state of a network interface changes or when a user logs in).
  • The package could install device inodes.
  • I would not expect development tools to match one of the above, and as such is not a high risk package.

If you have workflows in which you would make use of the development tools, then you first have to decide whether those are reasonable workflows, and if they are, you should install the development tools.

If you find that you don't really need those tools on the server, you should refrain from installing them for multiple reasons:

  • Saves disk space, both on the server and on backups.
  • Less installed software makes it easier to track what your dependencies are.
  • If you don't need the package, there is no point in taking the additional security risk from having it installed, even if that security risk is tiny.

If you decide that for security reasons, you won't allow unprivileged users to put their own executabels on the server, then what you should avoid is not the development tools but rather directories writable to those users on file systems mounted with execute permissions. There may still be a use for development tools even under those circumstances, but it is not very likely.

Other Projects

DARPA Open Source

Many branches of the US military are interested in open source.

NSA Open Source

The National Security Agency | Open Source Software & The Ghidra decompiler project, an interview of Jacob & Emily from the agency’s community team, as well as a software developer from the open source decompiler project Ghidra.

While most of what the NSA does is top secret, they actually have 40 open source projects and an active community team and public education programs. We talked about how they support open source at the NSA, cybersecurity, career paths in technology, learning new skills, and our tech origin stories.

Links mentioned in this episode:

Links related to this episode

References