Argo CD Deals With Our First Zero-Day CVE

Over the past 18 months, the Argo Project has really focused on improving security across the platform. In addition to completing a security audit at the beginning of 2021, creating better security response strategies, adding Snyk to scan for vulnerabilities, and now implementing fuzz testing, the project has been improving the overall approaches and posture towards security. Security isn’t something you can simply tack onto a project, it needs to be built into the DNA. With that preamble, we’d like to share how these better security policies helped us respond to CVE-2022–24348 in a quick and responsible fashion.

Vulnerability Limitations

• The attacker must already have access to deploy applications from Argo CD.
• The attacker must have the ability to modify the application’s source manifests (i.e. a Helm repo or git repo).
• Some other applications must involve secrets in YAML.

Either:

• Secrets must be stored in plaintext in the source Helm or git repo or
• secrets must be written to disk as part of the manifest generation in a plugin.

If you are not storing secrets in Helm or git repos in plaintext, and if you are not using plugins in Argo CD which can decrypt secrets, this vulnerability should not allow an attacker to access secrets.

Discovery of CVE-2022–24348

On January 30, 2022, security researchers at Apiiro discovered a vulnerability where attackers could construct a malicious Helm chart to exfiltrate secrets, tokens, and other sensitive information which could then be potentially used for privilege escalation. In order to load the malicious Helm chart, attackers would need to already be valid users within Argo CD. The security team at Apiiro alerted the Argo team immediately via the responsible disclosure outlined in the Argo CD Security policy. Those interested in the technical details can read the excellent write-up at Apiiro.

Security Response

Once the security team within Argo Project was notified, they immediately began working with Apiiro’s research group to identify a resolution. The Argo team released a fix within 48 hours on Feb 3 in concert with the public disclosure of the CVE and posted a security advisory to Argo CD users. In accordance with Argo CD support policies, patches were released for the latest 2 versions, as well as the latest RC branch (v2.3.0, v2.2.4, v2.1.9).

Dealing with security vulnerabilities and zero-day notifications is a muscle every software product team has to develop. In this case, the Argo team was able to work very quickly to resolve the issue and provide responsible disclosure.

Ultimately, as a team, the Argo community works very hard to maintain a proactive security approach and we’re grateful to the team at Apiiro for disclosing this issue responsibility. We’ll continue rolling out improvements to our security processes but are very happy to see how well the existing processes worked to address this issue.

If you’re interested in taking part in the process, Argo SIG Security meets bi-weekly to review potential issues and improve project security. You can find the meetings on the Argo project calendar.

Timeline

• Jan 30, 2022: Vulnerability reported to the Argo Project security team
• Jan 30, 2022: Argo team verified and acknowledged the bug
• Jan 31, 2022: Mutual continued triage to understand and discuss vulnerability’s extent and impact
• Feb 1, 2022: Argo team reported on progressive work on patches, fix and release schedule to Apiiro
• Feb 3, 2022: Synchronous release of advisories, patch, and blog

Credits

Special thanks to Moshe Zioni, VP, Security Research, Apiiro as well as the Argo maintainers that took such quick action. Credits to Michael Crenshaw for adding vulnerability limitations to this blog post.