Difference between revisions of "Open Source Security"

From MgmtWiki
Jump to: navigation, search
(→‎NSA Open Source)
(→‎Binary Analysis)
 
(78 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
==Full Title or Meme==
 
==Full Title or Meme==
−
[[Open Source Security]] technically applies to all software where the source code is available. In practice it often means software that is developed using open source tools.
+
[[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. Some specifications call these modules and components.
  
 
==Context==
 
==Context==
 +
* There is an assertion of long standing that [[Open Source Software]] is more secure because of the "Many Eyes" that review the code and local all bugs.
 +
* Currently there is an effort to increase the content of [[Open Source Software]] in DoD software, which has very high security requirements.
 +
* The AF CIO appointed in 2022-05, Lauren Knausenberger, has reprised the "Many Eyes" assertion as<ref>Lauren C. Williams. ''Why the USAF's IT chief is 'bullish' on open source'' FCW (2022-05-11) https://fcw.com/security/2022/05/why-usafs-it-chief-bullish-open-source/366836/</ref><blockquote>The same concerns are there whether it's commercial software or open source. But if it's open source software, you have the power of the crowd looking at it and then you can also run your own tests internally because it is open code…you can redo the work yourself if you so choose, </blockquote>
 +
* Interestingly the DoD has access to the source of code like Microsoft Windows, which would also allow the DoD to "redo the work" of checking the security of the code.
 +
* The Linux Foundation is supporting [[Open Source Security]] but is seems to be a case of wishful thinking. The problems are well address in a open discussion hosted in the CACM.<ref>May Kaczorowski+2, ''OSS Supply-Chain Security: What will it Take?''  '''CACM 66''' No 4 (2023-04) pp 48ff.</ref> Most open source is built by self-selected developers who are anxious to get something to market and then drift away lead a legacy code base with no one to maintain it. Not that the same problem does not exist in closed source systems where maintenance is often sent to off-shore programmers or less motivated workers. Even Microsoft and other major suppliers has a similar environment.
 +
 +
==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 are available for very few OSS packages 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 to the US Government use secure software development practices which are notably absent in the OSS hacker culture.
 +
* The was [https://www.whitehouse.gov/briefing-room/statements-releases/2022/01/13/readout-of-white-house-meeting-on-software-security/ a White House Meeting with OSS community] on 2022-01-13. The discussion focused on three topics:
 +
# Preventing security defects and vulnerabilities, which is a challenge for developers who are not paid for their work.
 +
# Improving the process for finding and fixing defects, which the participants thought should focus on the most-used code, rather than the code that was shipping to the US government now (odd!)
 +
# 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==
 
* A common problem with code that was developed in closed, even secretive, environments was often buggy and of unknown quality.
 
* 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.
+
* In fact code like OpenSSL had bugs that [https://www.cisa.gov/uscert/ncas/current-activity/2022/11/01/openssl-releases-security-update still cropping up in 2022.persisted for years before they were discovered and patched] and bugs [https://securitylabs.datadoghq.com/articles/openssl-november-1-vulnerabilities/ continue to be discovered] in 2022.
−
 
+
* [https://www.csoonline.com/article/3688911/at-least-one-open-source-vulnerability-found-in-84-of-code-bases-report.html#:~:text=At%20least%20one%20open%20source%20vulnerability%20found%20in,2023%2011%3A36%20am%20PST%20NDAB%20Creativity%20%2F%20Shutterstock At Least One Open Source Vulnerability Found in 84% of Code Bases] in 2023-02 from data reported in 2022. 63% of the open source code has a CVSS severity score of 7 or higher.
−
==Problem==
+
* An [https://techcrunch.com/2021/07/18/the-end-of-open-source/ effort by the University of Minnesota] has shown that a determined long-term effort could subvert the entire Linux security model. 2021-07-18
 
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.
+
* When contributors are solicited, anyone can offer to help. Generally, the motives of the contributors are not examined. With the advent of the Ukraine war, [https://www.wired.com/story/open-source-sabotage-protestware protest-ware is starting to inflect widely used packages].  "In some cases, open-source software has been modified to display anti-war overlays or other messages of solidarity with Ukraine. In at least one instance, though, a popular software package was modified to deploy a malicious data wiper on Russian and Belarusian computers. This wave of protests in open source comes just a couple of months after a seemingly unrelated incident in which a maintainer sabotaged two of his widely used open-source projects out of apparent frustration stemming from feeling overworked and under-compensated."
−
* 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.
+
* 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.
 +
* [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 makes it clear that no one really knew the full extent of their exposure to vulnerabilities in open-source code after this was reported. But in February 2022 a [https://www.nextgov.com/cybersecurity/2022/02/new-cyber-safety-board-pivots-tackle-log4j-vulnerabilities/361626/ New Cyber Safety Board Pivots to Tackle log4j Vulnerabilities] (2022-02-04) in NextGov.
 +
 
 +
===An Example Exploit===
 +
The unreferenced quotes in the section come from the CISA Safety Review<ref>CISA Safety Review Board, ''Review of the December 2021 Log4j Event'' DHS CISA (2022-07-11)
 +
https://www.cisa.gov/sites/default/files/publications/CSRB-Report-on-Log4-July-11-2022_508.pdf</ref> in July 2022, also see the wiki page on the [[Executive Order on Cybersecurity]] <blockquote>The infrastructure on which we rely daily has become deeply interconnected through the use of shared communications, software, and hardware, making it susceptible to vulnerabilities on a global scale. While the computing industry is maturing, our ability to handle risk and incidents in our digital ecosystems is not keeping pace. To address this gap, and to begin driving necessary systemic improvements, President Biden directed the establishment of the Cyber Safety Review Board (CSRB, or the Board) to review significant cyber incidents and provide “advice, information, or recommendations for improving cybersecurity and incident response practices and policy.”</blockquote>
 +
* Apache Log4j is a Java-based logging utility originally written by Ceki Gülcü. Version2 was released in the Apache Logging Service under the ownership of the Apache Software Foundation. In 2013  the Log4j team accepted a community-submitted feature intended to ease data storage and retrieval called “JNDI [Java Naming and Directory Interface™]  On 2021-12-09, a zero-day vulnerability involving arbitrary code execution in this addition was published by the Alibaba Cloud Security Team and given the descriptor "Log4Shell".<ref>What's the Deal with the Log4Shell Security Nightmare?". Lawfare. (2021-12-10) https://www.lawfareblog.com/whats-deal-log4shell-security-nightmare</ref> After that more vulnerabilities were discovered in Log4j It has been characterized by Tenable as "the single biggest, most critical vulnerability of the last decade".<ref>"Recently uncovered software flaw 'most critical vulnerability of the last decade'". The Guardian 2021-12-11 https://www.theguardian.com/technology/2021/dec/10/software-flaw-most-critical-vulnerability-log-4-shell</ref> [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44832 CVE-2021-44832] is the fourth attempt at a fix by Apache.
 +
* Still this code is deeply embedded in many products which may not even be aware of their dependency on it. The CISA Cyber Safety Review Board release on 2022-97-11 a [https://www.cisa.gov/sites/default/files/publications/CSRB-Report-on-Log4-July-11-2022_508.pdf Review of the December2021 Log4j Event] that told us that "vulnerable instances of Log4j will remain in systems for many years to come, perhaps a decade or longer."
 +
* The major take-away is that we cannot assume that open-source code is more secure just because it is open-sourced and widely deployed.
 +
* Without complete [[SBOM|Software Bill of Materials]] this will be a recurrent problem as more implementations embedding open-source code are seen to have unsuspected embeds.
 +
 
 +
===An Attack from North Korea===
 +
https://medium.com/checkmarx-security/lazarus-group-launches-first-open-source-supply-chain-attacks-targeting-crypto-sector-cabc626e404e
 +
 
 +
Lazarus Group Launches First Open Source Supply Chain Attacks Targeting Crypto Sector
 +
Yehuda Gelb
 +
checkmarx-security
 +
Yehuda Gelb
 +
 
 +
 
 +
Published in checkmarx-security 2023-08-03
  
 
==Development Solutions==
 
==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.
 
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.
+
* Make your own software is fine. make is merely a dependency tracking and automation framework. It is typically used in conjunction with compilers, though, and those preferably 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.
 +
* Open SSF is a Linux support Open Source Security Foundation that seeks to provide tools to help developers.<ref>Open Source Security Foundation https://openssf.org/</ref><blockquote>The Open Source Security Foundation (OpenSSF) is a cross-industry organization at the Linux Foundation that brings together the industry’s most important open source security initiatives and the individuals and companies that support them. The OpenSSF is committed to collaboration and working both upstream and with existing communities to advance open source security for all.</blockquote>
 +
 
 +
==Deployment Solutions==
 +
It is always best to catch bugs before they are delivered to production systems. Two broad categorizes are:
 +
===Bill of Materials===
 +
Bugs can be delivered in both hardware and software.
 +
===Binary Analysis===
 +
Binary Analysis can be performed on the product before or after installation on a computer system.
 +
* [https://unmitigatedrisk.com/?p=756 Rethinking How We Assess Risk in the Software We Rely On]<blockquote>If all we have is a binary, the only way to understand the risks it represents is to analyze it in the same way an attacker would. However, doing this at scale and making the analysis actionable is challenging. Recent advancements in machine learning and language development are key to addressing this challenge. Currently, tools that operate on binaries alone fall into two categories. The first are solutions akin to 1990s antivirus programs – matching binaries to known issues. The second category helps skilled professionals reverse engineer the binary’s contents more quickly.</blockquote>
  
 
==Production Solutions==
 
==Production Solutions==
Line 25: Line 73:
 
* The following points are based on those posted on https://serverfault.com/questions/595366/is-it-safe-for-a-production-server-to-have-make-installed by kasperd.
 
* The following points are based on those posted on https://serverfault.com/questions/595366/is-it-safe-for-a-production-server-to-have-make-installed by kasperd.
  
−
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.
+
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 road-bump 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.
 
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.
Line 34: Line 82:
 
* 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 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.
 
* 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.
+
* 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 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.
Line 42: Line 90:
 
* Less installed software makes it easier to track what your dependencies are.
 
* 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 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.
+
If you decide that for security reasons, you won't allow unprivileged users to put their own executables 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==
+
===Government Mandates===
 +
* Even the US congress has decided to step in (2022-09-26) with a bill to improve OSS.<ref>OpenSSF, ''The United States Securing Open Source Software Act: What You Need to Know'' (2202-09-27) https://openssf.org/blog/2022/09/27/the-united-states-securing-open-source-software-act-what-you-need-to-know/</ref> It seems the only problem the OSS community has with the bill is that is didn't blame other software equally with OSS. The OSS community complains when they are not treated equally with the existing software and also complains when they are treated equally. <blockquote>It’s very encouraging to see Congress taking affirmative steps to address cybersecurity challenges in the software supply chain. The US Congress’ focus on the critical role open-source software play matches the White House’s focus on these issues. Some of the ideas sound familiar to us – for example, the use of Software Bill of Materials ([[SBOM]]s), the importance of security practices of development, build, and release processes (SLSA levels, OpenSSF Scorecards, and the OpenSSF Best Practices badge are indicative industry indicators), and a call for a risk assessment framework echoes our “Risk Assessment Dashboard” stream from our Mobilization Plan. This suggests there are opportunities for OpenSSF to work on this together with government agencies as we would with any other organization. We also like the call for OSPOs to be piloted, as we believe they can play a key role in the secure use of OSS and more contributions upstream. Perhaps most importantly, there is an acknowledgment that there is a need to consider industry and the open-source software community. Surprisingly, some of the points discussed in the Log4Shell hearing are not part of the proposed legislation. For example, the hearing discussed that assessing third-party software should apply to all software (open source or closed source). As Brad Arkin, SVP and Chief Security and Trust Officer at Cisco testified, it would be a mistake to single out open source as a unique source of risk. Mr. Arkin stated: </blockquote>
 +
* Europe has determined that Open Source must take responsibility for Open Source Code.<ref>Brandon Vigliarolo, ''EU lawmakers finalize cyber security rules that panicked open source devs'' The Register (2023-12-04) https://www.theregister.com/2023/12/04/infosec_in_brief/?utm_source=dlvr.it</ref><blockquote>Once in force, which will happen 20 days after its adoption by Parliament and the Council, the CRA will require hardware and software makers to meet some intimidating targets. Included in the rule is a 24-hour disclosure period for any newly-discovered security flaw under active exploitation, five years of security patch support, thorough documentation of all security features, and more. As an after though they added "In order not to hamper innovation or research, free and open source software developed or supplied outside the course of a commercial activity should not be covered by this Regulation," which will take expensive lawyers to untangle.</blockquote>
  
 +
==Building Trust==
 +
MIT evaluated trust in OSS and found that the original problem of determining the source remains today. Although this decades-old approach is trled-and-true in a sense, it is far from perfect. One problem, Merrill notes, “is that people are bad at managing cryptographic keys, which consist of very long numbers, in a way that is secure and prevents them from getting lost.” People lose their passwords all the time, Merrill says. “And if a software developer were to lose the private key and then contact a user saying, ‘Hey, I have a new key,’ how would you know who that really is?”<ref>Steve Nadis, ''Boosting faith in the authenticity of open source software'' MIT CSAIL (2023-11-30) https://www.csail.mit.edu/news/boosting-faith-authenticity-open-source-software</ref><blockquote>Open source software—software that is freely distributed, along with its source code, so that copies, additions, or modifications can be readily made —is “everywhere,” to quote the 2023 Open Source Security and Risk Analysis Report. Ninety-six percent of the computer programs used by major industries include open source software, and seventy-six percent of those programs consists of open source software. But the percentage of software packages “containing security vulnerabilities remains troublingly high,” the report warned. </blockquote>
 +
 +
==US Military Projects==
 +
“People are realizing now: wait a minute, literally everything we do is underpinned by Linux,” says Dave Aitel, a cybersecurity researcher and former NSA computer security scientist. “This is a core technology to our society. Not understanding kernel security means we can’t secure critical infrastructure.” <ref>Patrick Howell O'Neil. ''The US military wants to understand the most important software on Earth'' Technology Review https://www.technologyreview.com/2022/07/14/1055894/us-military-sofware-linux-kernel-open-source/</ref> Open-source code runs on every computer on the planet—and keeps America’s critical infrastructure going. DARPA is worried about how well it can be trusted.
 +
===DARPA Open Source===
 +
Many branches of the US military are interested in open source.
 +
* [https://www.darpa.mil/program/open-programmable-secure-5g Open, Programmable, Secure 5G (OPS-5G)] from DARPA (2021) about an attempt to move computing to the edge, that is into the field, rather than completely centralized.
 
===NSA Open Source===
 
===NSA Open Source===
−
 
+
* [https://code.nsa.gov Open Source @ NSA]
−
* [https://www.fedscoop.com/nsa-training-tool-github-skilltree/ open source training platform for apps, development]  
+
* [https://www.fedscoop.com/nsa-training-tool-github-skilltree/ open-source training platform for apps, development] 2020-10-16
 +
* [https://www.nsa.gov/Portals/70/documents/what-we-do/research/technology-transfer/oss_booklet.pdf?ver=2018-08-07-103751-707 Open Source Software Releases] of code that the NSA has put in the public domain, many on GitHub.
 
* The following is from the article https://developer.ibm.com/solutions/security/podcasts/ibm_developer_podcast/009_nsa_ghidra_open_source/. 2019-11-25
 
* The following is from the article https://developer.ibm.com/solutions/security/podcasts/ibm_developer_podcast/009_nsa_ghidra_open_source/. 2019-11-25
  
−
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.
+
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.
 
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.
Line 68: Line 127:
  
 
==References==
 
==References==
 +
<references />
 +
===Other Material===
 
* For details on OSS and FOSS see the wiki page [[Open Source Software]].
 
* For details on OSS and FOSS see the wiki page [[Open Source Software]].
  
 
[[Category: Profile]]
 
[[Category: Profile]]
 
[[Category: Best Practice]]
 
[[Category: Best Practice]]

Latest revision as of 22:29, 14 January 2024

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. Some specifications call these modules and components.

Context

  • There is an assertion of long standing that Open Source Software is more secure because of the "Many Eyes" that review the code and local all bugs.
  • Currently there is an effort to increase the content of Open Source Software in DoD software, which has very high security requirements.
  • The AF CIO appointed in 2022-05, Lauren Knausenberger, has reprised the "Many Eyes" assertion as[1]
    The same concerns are there whether it's commercial software or open source. But if it's open source software, you have the power of the crowd looking at it and then you can also run your own tests internally because it is open code…you can redo the work yourself if you so choose,
  • Interestingly the DoD has access to the source of code like Microsoft Windows, which would also allow the DoD to "redo the work" of checking the security of the code.
  • The Linux Foundation is supporting Open Source Security but is seems to be a case of wishful thinking. The problems are well address in a open discussion hosted in the CACM.[2] Most open source is built by self-selected developers who are anxious to get something to market and then drift away lead a legacy code base with no one to maintain it. Not that the same problem does not exist in closed source systems where maintenance is often sent to off-shore programmers or less motivated workers. Even Microsoft and other major suppliers has a similar environment.

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 are available for very few OSS packages 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 to the US Government use secure software development practices which are notably absent in the 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 participants thought should focus on the most-used code, rather than the code that was shipping to the US government now (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.
  • When contributors are solicited, anyone can offer to help. Generally, the motives of the contributors are not examined. With the advent of the Ukraine war, protest-ware is starting to inflect widely used packages. "In some cases, open-source software has been modified to display anti-war overlays or other messages of solidarity with Ukraine. In at least one instance, though, a popular software package was modified to deploy a malicious data wiper on Russian and Belarusian computers. This wave of protests in open source comes just a couple of months after a seemingly unrelated incident in which a maintainer sabotaged two of his widely used open-source projects out of apparent frustration stemming from feeling overworked and under-compensated."
  • 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 knew the full extent of their exposure to vulnerabilities in open-source code after this was reported. But in February 2022 a New Cyber Safety Board Pivots to Tackle log4j Vulnerabilities (2022-02-04) in NextGov.

An Example Exploit

The unreferenced quotes in the section come from the CISA Safety Review[3] in July 2022, also see the wiki page on the Executive Order on Cybersecurity
The infrastructure on which we rely daily has become deeply interconnected through the use of shared communications, software, and hardware, making it susceptible to vulnerabilities on a global scale. While the computing industry is maturing, our ability to handle risk and incidents in our digital ecosystems is not keeping pace. To address this gap, and to begin driving necessary systemic improvements, President Biden directed the establishment of the Cyber Safety Review Board (CSRB, or the Board) to review significant cyber incidents and provide “advice, information, or recommendations for improving cybersecurity and incident response practices and policy.”
  • Apache Log4j is a Java-based logging utility originally written by Ceki Gülcü. Version2 was released in the Apache Logging Service under the ownership of the Apache Software Foundation. In 2013 the Log4j team accepted a community-submitted feature intended to ease data storage and retrieval called “JNDI [Java Naming and Directory Interface™] On 2021-12-09, a zero-day vulnerability involving arbitrary code execution in this addition was published by the Alibaba Cloud Security Team and given the descriptor "Log4Shell".[4] After that more vulnerabilities were discovered in Log4j It has been characterized by Tenable as "the single biggest, most critical vulnerability of the last decade".[5] CVE-2021-44832 is the fourth attempt at a fix by Apache.
  • Still this code is deeply embedded in many products which may not even be aware of their dependency on it. The CISA Cyber Safety Review Board release on 2022-97-11 a Review of the December2021 Log4j Event that told us that "vulnerable instances of Log4j will remain in systems for many years to come, perhaps a decade or longer."
  • The major take-away is that we cannot assume that open-source code is more secure just because it is open-sourced and widely deployed.
  • Without complete Software Bill of Materials this will be a recurrent problem as more implementations embedding open-source code are seen to have unsuspected embeds.

An Attack from North Korea

https://medium.com/checkmarx-security/lazarus-group-launches-first-open-source-supply-chain-attacks-targeting-crypto-sector-cabc626e404e

Lazarus Group Launches First Open Source Supply Chain Attacks Targeting Crypto Sector Yehuda Gelb checkmarx-security Yehuda Gelb


Published in checkmarx-security 2023-08-03

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 your own software is fine. make is merely a dependency tracking and automation framework. It is typically used in conjunction with compilers, though, and those preferably 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.
  • Open SSF is a Linux support Open Source Security Foundation that seeks to provide tools to help developers.[6]
    The Open Source Security Foundation (OpenSSF) is a cross-industry organization at the Linux Foundation that brings together the industry’s most important open source security initiatives and the individuals and companies that support them. The OpenSSF is committed to collaboration and working both upstream and with existing communities to advance open source security for all.

Deployment Solutions

It is always best to catch bugs before they are delivered to production systems. Two broad categorizes are:

Bill of Materials

Bugs can be delivered in both hardware and software.

Binary Analysis

Binary Analysis can be performed on the product before or after installation on a computer system.

  • Rethinking How We Assess Risk in the Software We Rely On
    If all we have is a binary, the only way to understand the risks it represents is to analyze it in the same way an attacker would. However, doing this at scale and making the analysis actionable is challenging. Recent advancements in machine learning and language development are key to addressing this challenge. Currently, tools that operate on binaries alone fall into two categories. The first are solutions akin to 1990s antivirus programs – matching binaries to known issues. The second category helps skilled professionals reverse engineer the binary’s contents more quickly.

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 road-bump 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 executables 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.

Government Mandates

  • Even the US congress has decided to step in (2022-09-26) with a bill to improve OSS.[7] It seems the only problem the OSS community has with the bill is that is didn't blame other software equally with OSS. The OSS community complains when they are not treated equally with the existing software and also complains when they are treated equally.
    It’s very encouraging to see Congress taking affirmative steps to address cybersecurity challenges in the software supply chain. The US Congress’ focus on the critical role open-source software play matches the White House’s focus on these issues. Some of the ideas sound familiar to us – for example, the use of Software Bill of Materials (SBOMs), the importance of security practices of development, build, and release processes (SLSA levels, OpenSSF Scorecards, and the OpenSSF Best Practices badge are indicative industry indicators), and a call for a risk assessment framework echoes our “Risk Assessment Dashboard” stream from our Mobilization Plan. This suggests there are opportunities for OpenSSF to work on this together with government agencies as we would with any other organization. We also like the call for OSPOs to be piloted, as we believe they can play a key role in the secure use of OSS and more contributions upstream. Perhaps most importantly, there is an acknowledgment that there is a need to consider industry and the open-source software community. Surprisingly, some of the points discussed in the Log4Shell hearing are not part of the proposed legislation. For example, the hearing discussed that assessing third-party software should apply to all software (open source or closed source). As Brad Arkin, SVP and Chief Security and Trust Officer at Cisco testified, it would be a mistake to single out open source as a unique source of risk. Mr. Arkin stated:
  • Europe has determined that Open Source must take responsibility for Open Source Code.[8]
    Once in force, which will happen 20 days after its adoption by Parliament and the Council, the CRA will require hardware and software makers to meet some intimidating targets. Included in the rule is a 24-hour disclosure period for any newly-discovered security flaw under active exploitation, five years of security patch support, thorough documentation of all security features, and more. As an after though they added "In order not to hamper innovation or research, free and open source software developed or supplied outside the course of a commercial activity should not be covered by this Regulation," which will take expensive lawyers to untangle.

Building Trust

MIT evaluated trust in OSS and found that the original problem of determining the source remains today. Although this decades-old approach is trled-and-true in a sense, it is far from perfect. One problem, Merrill notes, “is that people are bad at managing cryptographic keys, which consist of very long numbers, in a way that is secure and prevents them from getting lost.” People lose their passwords all the time, Merrill says. “And if a software developer were to lose the private key and then contact a user saying, ‘Hey, I have a new key,’ how would you know who that really is?”[9]
Open source software—software that is freely distributed, along with its source code, so that copies, additions, or modifications can be readily made —is “everywhere,” to quote the 2023 Open Source Security and Risk Analysis Report. Ninety-six percent of the computer programs used by major industries include open source software, and seventy-six percent of those programs consists of open source software. But the percentage of software packages “containing security vulnerabilities remains troublingly high,” the report warned.

US Military Projects

“People are realizing now: wait a minute, literally everything we do is underpinned by Linux,” says Dave Aitel, a cybersecurity researcher and former NSA computer security scientist. “This is a core technology to our society. Not understanding kernel security means we can’t secure critical infrastructure.” [10] Open-source code runs on every computer on the planet—and keeps America’s critical infrastructure going. DARPA is worried about how well it can be trusted.

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

  1. ↑ Lauren C. Williams. Why the USAF's IT chief is 'bullish' on open source FCW (2022-05-11) https://fcw.com/security/2022/05/why-usafs-it-chief-bullish-open-source/366836/
  2. ↑ May Kaczorowski+2, OSS Supply-Chain Security: What will it Take? CACM 66 No 4 (2023-04) pp 48ff.
  3. ↑ CISA Safety Review Board, Review of the December 2021 Log4j Event DHS CISA (2022-07-11) https://www.cisa.gov/sites/default/files/publications/CSRB-Report-on-Log4-July-11-2022_508.pdf
  4. ↑ What's the Deal with the Log4Shell Security Nightmare?". Lawfare. (2021-12-10) https://www.lawfareblog.com/whats-deal-log4shell-security-nightmare
  5. ↑ "Recently uncovered software flaw 'most critical vulnerability of the last decade'". The Guardian 2021-12-11 https://www.theguardian.com/technology/2021/dec/10/software-flaw-most-critical-vulnerability-log-4-shell
  6. ↑ Open Source Security Foundation https://openssf.org/
  7. ↑ OpenSSF, The United States Securing Open Source Software Act: What You Need to Know (2202-09-27) https://openssf.org/blog/2022/09/27/the-united-states-securing-open-source-software-act-what-you-need-to-know/
  8. ↑ Brandon Vigliarolo, EU lawmakers finalize cyber security rules that panicked open source devs The Register (2023-12-04) https://www.theregister.com/2023/12/04/infosec_in_brief/?utm_source=dlvr.it
  9. ↑ Steve Nadis, Boosting faith in the authenticity of open source software MIT CSAIL (2023-11-30) https://www.csail.mit.edu/news/boosting-faith-authenticity-open-source-software
  10. ↑ Patrick Howell O'Neil. The US military wants to understand the most important software on Earth Technology Review https://www.technologyreview.com/2022/07/14/1055894/us-military-sofware-linux-kernel-open-source/

Other Material

Retrieved from "http://tcwiki.azurewebsites.net/index.php?title=Open_Source_Security&oldid=19598"