This blog post is a part of Mattermost’s public disclosure of three serious vulnerabilities in Go’s encoding/xml related to tokenization round-trips. The public disclosure comes as a result of several months of work, including collaborating with the Go security team since August 2020 and with affected downstream project maintainers since earlier this month.

The upstream Kubernetes community recently discovered a security issue—CVE-2020-8554— affecting multitenant clusters that allows anyone who is able to create a ClusterIP service and set the spec.externalIPs field to intercept traffic to that IP address. There is no patch for this issue yet, and it can currently only be mitigated by restricting access to the vulnerable features.

Vulnerability remediation is still an ongoing struggle for organizations. A simple mistake could cause no issues, or it could set off a wide-scale, devastating, corporate breach. Why is this? There are many reasons. Security and Ops talk past one another. No one wants to be the one that broke something. Speed is hindered by ineffective testing.

While auditing the Kubernetes source code, I recently discovered an issue (CVE-2020-8566) in Kubernetes that may cause sensitive data leakage. You would be affected by CVE-2020-8566 if you created a Kubernetes cluster using ceph cluster as storage class, with logging level set to four or above in kube-controller-manager. In that case, your ceph user credentials will be leaked in the cloud-controller-manager‘s log.

Threat actors can move pretty fast. There are untold numbers of adversaries operating in the shadows looking for the next vulnerability they can exploit. Sometimes they find a vulnerability that hasn’t been identified by white-hat researchers or the vendors—resulting in a zero-day exploit—but most often they watch for public disclosures and updates from vendors to identify changes that have occurred in code.

Using open source code makes it easier to build applications, but the freely available nature of open source code introduces the risk of pulling potential security vulnerabilities into your environment. Knowing whether or not customers are actually accessing the vulnerable parts of your application is key to triaging security threats without spending hours fixing an issue that doesn’t affect end users.

Common Vulnerability Scoring System (CVSS) scores have been viewed as the de facto measure to prioritize vulnerabilities. Vulnerabilities are assigned CVSS scores ranging from one to 10, with 10 being the most severe. However, they were never intended as a means of risk prioritization. If you’ve relied on CVSS scores alone to safeguard your organization, here’s why you’re probably using them incorrectly.

An Elastic Security Advisory (ESA) is a notice from Elastic to its users of a new Elasticsearch vulnerability. The vendor assigns both a CVE and an ESA identifier to each advisory along with a summary and remediation details. When Elastic receives an issue, they evaluate it and, if the vendor decides it is a vulnerability, work to fix it before releasing a remediation in a timeframe that matches the severity.

While auditing the Kubernetes source code, I recently discovered an issue (CVE-2020-8563) in Kubernetes that may cause sensitive data leakage. You would be affected by CVE-2020-8563 if you created a Kubernetes cluster over vSphere, and enabled vSphere as a cloud provider with logging level set to 4 or above. In that case, your vSphere user credentials will be leaked in the cloud-controller-manager‘s log.