Stories with Tag Open Source Security

• Supply Chain Attacks on Linux Distributions – Fedora Pagure

  permalink

  Posted: 2025-03-19 19:58:37

  Verbose tl;dr

  The blog post details a potential supply chain attack vector targeting Linux distributions, specifically focusing on Fedora's now-deprecated Pagure code hosting platform. The author discovered that Pagure's design allowed maintainers to incorporate external dependencies, such as automatically fetched tarballs from arbitrary URLs, directly into build processes. This posed a significant security risk as compromised external servers could inject malicious code into these dependencies, which would then be incorporated into Fedora packages. While Fedora itself wasn't directly affected due to its use of mock for isolated builds, the author argues the vulnerability highlighted a broader systemic issue in open-source software supply chains where implicit trust in external resources can be exploited. The post concludes by emphasizing the need for stricter dependency management and verification practices within Linux distributions and the open-source ecosystem.

  This blog post details a potential supply chain attack vector targeting Linux distributions, specifically focusing on the Fedora Project's now-deprecated code forging platform, Pagure. The author, known as "fenris," meticulously outlines how a compromised Pagure instance could have devastating consequences for the entire Fedora ecosystem and potentially other distributions that consume Fedora packages.

  Fenris begins by explaining Pagure's role as a git-based code repository and review platform where Fedora developers collaborated on software projects. Crucially, Pagure housed the spec files, the recipes that dictate how software is built into installable RPM packages. Compromising Pagure, therefore, would offer an attacker an ideal position to inject malicious code into these spec files, which would then be incorporated into the final RPM packages distributed to Fedora users.

  The attack scenario envisioned by fenris involves a malicious actor gaining unauthorized access to Pagure’s server infrastructure. This could be achieved through various means, such as exploiting software vulnerabilities, obtaining compromised credentials, or leveraging social engineering tactics. Once inside, the attacker could subtly alter spec files, injecting malicious commands that would execute during the build process or after the package is installed on a user's system. These malicious modifications could range from installing backdoors, exfiltrating sensitive data, or even crippling system functionality.

  The post emphasizes the insidious nature of such an attack. Because the malicious code resides within the spec file itself, it bypasses typical security measures like code review. Developers, trusting the integrity of the Pagure platform, might not detect the subtle changes within the seemingly innocuous spec file updates. Consequently, the malicious code would propagate through the build system, ultimately contaminating the official Fedora repositories and reaching end users.

  Fenris underscores the far-reaching impact of this potential vulnerability. Not only would Fedora users be at risk, but other Linux distributions, like Red Hat Enterprise Linux (RHEL) and CentOS Stream, which often derive packages from Fedora, could also be affected. This cascading effect highlights the interconnectedness of the open-source ecosystem and the potential for a single point of compromise to have widespread ramifications.

  The post concludes by highlighting the significance of securing the software supply chain and advocates for robust security measures throughout the development and distribution process. While acknowledging that Fedora has since migrated from Pagure to GitLab, the post serves as a cautionary tale, emphasizing the need for continuous vigilance against potential supply chain attacks and the importance of implementing secure development practices across the open-source landscape. The author emphasizes that while the specific vulnerability relating to Pagure is no longer relevant, the overall methodology described represents a persistent threat that needs to be considered for any platform hosting build instructions and source code.

  • Supply Chain Security
  • Linux
  • Fedora
  • Pagure
  • software supply chain
  • Cybersecurity
  • Open Source Security
  • Software Repositories
  • package management
  • Vulnerability
  • Security Audit
  • Compromise
  • Attack Vectors

  Summary of Comments ( 67 )
  https://news.ycombinator.com/item?id=43416605

  Verbose tl;dr

  HN commenters discuss the complexities of securing the software supply chain, particularly for Linux distributions. Some express skepticism about the feasibility of perfect security, noting the difficulty in verifying every component and the potential for vulnerabilities to be introduced at various stages. Others suggest focusing on minimizing the "blast radius" of potential attacks through techniques like reproducible builds and better compartmentalization. The conversation also touches on the trade-offs between security and convenience, with some arguing that the current level of risk is acceptable given the benefits of open-source software and rapid development cycles. A few comments delve into specific technical details, such as the use of signed RPM packages and the role of distribution maintainers in verifying software integrity. Finally, there's a discussion about the potential for malicious actors to target infrastructure like package repositories and the importance of robust security measures at that level.

  The Hacker News post "Supply Chain Attacks on Linux Distributions – Fedora Pagure" sparked a discussion with several insightful comments focusing on the complexities and challenges of securing the software supply chain, particularly within the context of Linux distributions.

  One commenter highlighted the inherent difficulty of preventing all forms of supply chain attacks, emphasizing that determined adversaries will always find new and creative ways to exploit vulnerabilities. They suggested that focusing solely on prevention is insufficient and advocated for a multi-layered approach that includes robust detection and mitigation strategies. This commenter also touched on the need for better tooling to help identify and address potential weaknesses.

  Another commenter pointed out the crucial role of reproducible builds in enhancing security. Reproducible builds allow independent verification of the compiled binaries, ensuring they match the source code. This helps detect malicious modifications introduced during the build process, increasing confidence in the integrity of the software. They further mentioned the challenges associated with achieving full reproducibility, particularly with complex software projects and varying build environments.

  The conversation also touched on the specific challenges faced by smaller projects like Pagure, the software discussed in the linked article. A commenter noted that smaller projects often lack the resources and expertise to implement comprehensive security measures. This contributes to a broader ecosystem vulnerability, as even seemingly insignificant projects can become entry points for attackers targeting larger systems.

  Several comments delved into the technical details of potential attack vectors, discussing methods like compromising build servers or injecting malicious code into dependencies. These comments highlighted the intricate nature of the software supply chain and the numerous points where vulnerabilities can arise.

  One commenter questioned the focus on Pagure specifically, suggesting that the issues discussed are widespread and not unique to this particular project. They argued that the broader problem lies in the complexity of modern software development and the interconnectedness of various components, making it challenging to secure every link in the chain.

  Finally, a commenter emphasized the importance of user education and awareness in mitigating supply chain attacks. They suggested that developers and users alike need to be more vigilant about the software they use and the sources from which they obtain it, advocating for a culture of security consciousness throughout the software ecosystem.

  In summary, the comments on the Hacker News post provide a nuanced and multifaceted perspective on the challenges of securing the software supply chain, moving beyond simply acknowledging the problem to explore potential solutions and highlight the need for a comprehensive and collaborative approach.

• Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos

  permalink

  Posted: 2025-03-14 22:29:46

  Verbose tl;dr

  The popular GitHub Action tj-actions/changed-files was compromised and used to inject malicious code into projects that utilized it. The attacker gained access to the action's repository and added code that exfiltrated environment variables, secrets, and other sensitive information during workflow runs. This action, used by over 23,000 repositories, became a supply chain vulnerability, potentially affecting numerous downstream projects. The maintainers have since regained control and removed the malicious code, but users are urged to review their workflows and rotate any potentially compromised secrets.

  The blog post "Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos" by Step Security details a security incident involving a popular GitHub Action, tj-actions/changed-files, which was compromised and used to inject malicious code into the build processes of repositories that depended on it. This action, utilized by over 23,000 repositories, provided a convenient way to identify files changed in a given commit, a common requirement for optimizing workflows.

  The attacker gained control of the tj-actions/changed-files repository by compromising the maintainer's account. They then introduced a malicious commit, specifically version 3.6.0, that included a backdoor. This backdoor injected a malicious script, ./setup.sh, disguised as a harmless setup script. When the compromised action was executed, this script would download and execute a second-stage payload from a remote server controlled by the attacker. This second payload was capable of exfiltrating sensitive information, such as environment variables, secrets, and repository contents, from the affected workflows.

  The blog post emphasizes the severe security implications of this type of supply chain attack, where a compromised dependency can affect a large number of downstream users. It highlights the importance of verifying the integrity and provenance of third-party actions before incorporating them into CI/CD pipelines.

  The post outlines several mitigation strategies for those who may have used the compromised version. These include immediately reviewing workflow logs for suspicious activity, rotating any potentially exposed secrets, and pinning the action to a known safe version (such as 3.5.1 or earlier) or migrating to an alternative solution. The post specifically suggests the dorny/paths-filter action as a secure replacement.

  Furthermore, the article discusses broader best practices for securing GitHub Actions workflows. It recommends using OpenID Connect (OIDC) to limit the need for long-lived secrets, enabling branch protection rules to prevent unauthorized modifications to workflows, and adopting least-privilege access for GitHub Actions tokens. It also advocates for the development of mechanisms to detect anomalous behavior in workflows and alert administrators to potential compromises, such as unexpected network connections or the execution of unfamiliar scripts. The incident underlines the critical need for continuous vigilance and proactive security measures in the software supply chain.

  • GitHub
  • GitHub Actions
  • Security
  • Software Supply Chain Security
  • Supply Chain Attack
  • Compromised Action
  • tj-actions/changed-files
  • Software Security
  • Cybersecurity
  • Open Source Security
  • Dependency Security
  • Vulnerability
  • malicious code
  • code injection
  • Security Best Practices
  • Security Alert

  Summary of Comments ( 205 )
  https://news.ycombinator.com/item?id=43367987

  Verbose tl;dr

  Hacker News users discussed the implications of the tj-actions/changed-files compromise, focusing on the surprising longevity of the vulnerability (2 years) and the potential impact on the 23,000+ repositories using it. Several commenters questioned the security practices of relying on third-party GitHub Actions without thorough vetting, emphasizing the need for auditing dependencies and using pinned versions. The ease with which a seemingly innocuous action could be compromised highlighted the broader security risks within the software supply chain. Some users pointed out the irony of a security-focused action being the source of vulnerability, while others discussed the challenges of maintaining open-source projects and the pressure to keep dependencies updated. A few commenters also suggested alternative approaches for achieving similar functionality without relying on third-party actions.

  The Hacker News post discussing the compromise of the tj-actions/changed-files GitHub Action has a substantial number of comments exploring various facets of the incident and its implications.

  Several commenters discuss the nature of the vulnerability and the attacker's approach. Some point out the seemingly unsophisticated nature of the attack, highlighting the injected code's straightforward execution of a malicious payload without much obfuscation or stealth. Others analyze the specific mechanism of the compromise, noting how the attacker gained access to the maintainer's account and modified the action to include the malicious script. The relative ease with which this popular action was compromised raises concerns about the security of the software supply chain and the potential for similar attacks in the future.

  A significant thread of discussion revolves around the responsibilities of open-source maintainers and the challenges they face. Commenters acknowledge the substantial workload often borne by maintainers who volunteer their time and expertise. The incident underscores the difficulty of securing open-source projects, particularly those with a large user base, and the potential consequences of compromised dependencies. Some suggest potential solutions, including increased scrutiny of third-party actions, improved security practices for maintainers, and the development of tools to detect malicious code in actions. The discussion also touches upon the financial aspect of open-source maintenance and the need for better support and resources for maintainers.

  Several users express frustration with GitHub's handling of the situation, particularly the perceived lack of communication and transparency. Some commenters criticize the platform's security measures and suggest improvements, such as stricter verification processes for actions and more robust mechanisms for detecting and responding to compromises. Others point out the difficulty of verifying the integrity of third-party code and the need for better tools and practices to address this challenge.

  The impact of the compromise on the broader software ecosystem is also a topic of discussion. Commenters speculate on the potential consequences for the thousands of repositories that rely on the affected action, including the possibility of data breaches and other security incidents. The incident highlights the interconnected nature of the software supply chain and the potential for widespread damage from a single compromised component. Some users share their experiences dealing with the fallout from the incident, including the steps they took to mitigate the risk and ensure the security of their projects.

  Finally, there's a thread discussing the importance of supply chain security in general and the need for increased vigilance and proactive measures to protect against similar attacks in the future. Commenters suggest various strategies, including code signing, multi-factor authentication, and regular security audits. The incident serves as a wake-up call for the software development community, emphasizing the need for a more robust and secure approach to managing dependencies and protecting the software supply chain.

• Sigstore: Making sure your software is what it claims to be

  permalink

  Posted: 2025-01-21 20:34:14

  Verbose tl;dr

  Sigstore aims to solve the problem of software supply chain security by making it easy to sign software artifacts and verify those signatures. It provides free tooling and a public good transparency log, enabling developers to sign releases with short-lived certificates tied to their identities (e.g., GitHub and email). This allows users to easily verify the provenance and integrity of software, ensuring that it hasn't been tampered with and genuinely originates from the claimed source. Sigstore simplifies the complex process of code signing, removing the need for managing long-lived keys and complicated infrastructure. This makes it significantly more practical for developers to secure their software supply chains and builds trust with end users.

  Sigstore is a free and open-source service designed to dramatically improve the security of the software supply chain. It addresses the critical problem of ensuring that software you download and run is genuinely what it claims to be, originating from the expected source and not tampered with along the way. This is achieved through a novel combination of transparency, automation, and cryptographic verification using digital signatures, similar to how HTTPS secures web browsing, but applied specifically to software artifacts.

  Traditionally, verifying the provenance and integrity of software has been complex, often relying on manual processes and cumbersome key management practices. Sigstore streamlines this process by automating the generation and management of short-lived cryptographic keys, eliminating the need for developers to maintain their own long-term signing keys, which can be a significant security vulnerability if compromised. These ephemeral keys are tied to identities through OpenID Connect (OIDC), a widely adopted authentication standard used by many major identity providers. This allows developers to leverage their existing organizational identities to sign their software, simplifying the authentication process and making it more secure.

  The signed attestations, along with the software artifacts themselves, are then stored in a tamper-proof public transparency log called Rekor. This log provides a permanent and auditable record of all signed software releases, allowing anyone to independently verify the integrity and authenticity of a particular software artifact. This significantly enhances transparency within the software supply chain, making it easier to detect malicious attempts to introduce compromised software. Because the log is publicly searchable, users can verify a signature even if they don't trust the publisher directly.

  Fulcio, Sigstore's free certificate authority, issues short-lived certificates linking the signing identity and the ephemeral key. This eliminates the need for developers to manage and secure their own code signing certificates, further streamlining the signing process and minimizing the attack surface. The integration with OIDC allows developers to use their existing identity provider, making the process seamless and easily integrated into existing workflows.

  By combining keyless signing, transparency logs, and a free certificate authority, Sigstore provides a powerful and comprehensive solution for securing the software supply chain. It empowers developers to sign and verify software easily and securely, while providing end-users with the assurance that the software they are using is trustworthy and has not been tampered with. This contributes significantly to improving the overall security posture of the software ecosystem by making it more difficult for attackers to distribute malicious code disguised as legitimate software. The open-source nature of the project fosters community involvement and allows for independent audits and scrutiny, further strengthening trust in the system.

  • Software Supply Chain Security
  • Sigstore
  • Software Signing
  • Digital Signatures
  • Open Source Security
  • software verification
  • Supply Chain Attacks
  • Code Signing
  • Security
  • DevOps
  • SLSA
  • Software Integrity
  • Provenance

  Summary of Comments ( 5 )
  https://news.ycombinator.com/item?id=42784892

  Verbose tl;dr

  Hacker News commenters generally expressed strong support for Sigstore and its mission of improving software supply chain security. Several praised its ease of use and integration with existing tools, noting the significantly lowered barrier to entry for signing releases compared to traditional methods. Some highlighted the importance of key transparency and the clever use of OpenID Connect for identity verification. A few commenters discussed the potential impact on various ecosystems like Debian and Python, expressing hope for wider adoption and speculating on the future development of the project. Concerns were raised about the reliance on centralized services and potential single points of failure, but these were often met with counter-arguments about the federated nature of OpenID and the transparency of the log. Some users questioned the long-term viability of free certificate issuance, and others debated the nuances of different signing models and their relative security implications.

  The Hacker News post titled "Sigstore: Making sure your software is what it claims to be" (linking to sigstore.dev) generated a moderate amount of discussion with a mix of praise for the project, inquiries about its practical application, and comparisons to other security initiatives.

  Several commenters expressed enthusiasm for Sigstore, emphasizing its potential to significantly improve software supply chain security. One user highlighted the ease of use and integration with existing tools as major advantages, particularly for open-source projects where maintaining complex security infrastructure can be challenging. Another lauded the transparency and auditability provided by the public log, making it easier to track the provenance of software artifacts. The simplicity of key management using OpenID Connect was also mentioned favorably, eliminating the need for developers to manage their own private keys.

  Some commenters focused on practical considerations and sought clarification on specific aspects of Sigstore. One user questioned how Sigstore handles dependencies, asking whether it verifies the signatures of all dependencies recursively. Another raised concerns about the revocation process, wondering how compromised keys would be handled and what impact that would have on the integrity of signed artifacts. There was also a discussion about the reliance on certificate transparency logs, with some users expressing concerns about the potential for log manipulation or censorship.

  Comparisons were drawn to other security initiatives like The Update Framework (TUF) and in-toto. One commenter pointed out that while TUF addresses similar security concerns, Sigstore simplifies key management and signature verification, potentially making it more accessible to a wider range of developers. Another user noted the similarities between Sigstore and in-toto, particularly in their use of transparency logs, but highlighted Sigstore's focus on code signing as a differentiating factor.

  A few commenters expressed skepticism about the project's long-term viability, questioning whether it would gain widespread adoption and whether it truly addressed the complex challenges of software supply chain security. One user raised concerns about the potential for "security theater," suggesting that Sigstore might provide a false sense of security without addressing the root causes of vulnerabilities.

  Overall, the comments reflect a general interest in Sigstore and its potential to improve software security, but also reveal some valid concerns and questions about its practical implementation and long-term effectiveness. The discussion highlights the complexity of the software supply chain security problem and the need for multifaceted solutions.