CVE Announce e-newsletter — April 29, 2021
Welcome to the latest issue of the CVE Announce e-newsletter. This newsletter is intended to keep you up to date on recent news about CVE, such as advancements in the program, new CNAs, CVE in the news, and more. The mission of the CVE® Program is to identify, define, and catalog publicly disclosed cybersecurity vulnerabilities. The CVE Board provides oversight and input into CVE’s strategic direction, ensuring CVE meets the vulnerability identification needs of the global technology community. CVE Numbering Authorities (CNAs) consist of vendors, open source projects, vulnerability researchers, hosted service providers, industry and national CERTs, and bug bounty programs authorized to assign CVE Identifiers (CVE IDs) to newly discovered issues and include the CVE IDs in the first public disclosure of the vulnerabilities.
Contents:
1. 13 New CVE Numbering Authorities (CNAs)
2. Our CVE Story: An Open-Source, Community-Based Example
3. My CVE Story: How I Became the CVE Program’s First Vulnerability Researcher CNA
4. We Speak CVE Podcast – New Episodes!
13 New CVE Numbering Authorities (CNAs)
Thirteen additional organizations are now CNAs: (1) Arista Networks, Inc. for all Arista products only; (2) Axis Communications AB for Axis products and solutions only; (3) DeepSurface Security, Inc. for all DeepSurface products, as well as vulnerabilities in third-party software discovered by DeepSurface that are not in another CNA’s scope; (4) Environmental Systems Research Institute, Inc. (Esri) for all Esri products only; (5) Mautic for Mautic core and officially supported plugins; (6) NEC Corporation for NEC issues only; (7) Octopus Deploy for all Octopus Deploy products, as well as Octopus Deploy maintained projects hosted on github.com/OctopusDeploy; (8) Simplinx Ltd. Simplinx products only; (9) Synopsys for all Synopsys SIG products, as well as vulnerabilities in third-party software discovered by Synopsys SIG that are not in another CNA’s scope; (10) Vaadin Ltd. for all Vaadin products and supported open-source projects hosted at github.com/vaadin; (11) Xen Project for all sub-projects under Xen Project’s umbrella, except those sub-projects that have their own security response process, plus the Xen components inside other projects where Xen Project is the primary developer; (12) Xylem for Xylem products and technologies only; and (13) Zoom Video Communications, Inc. for Zoom and Keybase issues only.
To date, 165 organizations from 27 countries participate in the CVE Program as CNAs. CNAs are organizations from around the world that are authorized to assign CVE IDs to vulnerabilities affecting products within their distinct, agreed-upon scope, for inclusion in first-time public announcements of new vulnerabilities.
To request a CVE ID number from a CNA, visit Request a CVE ID on the CVE website.
Read on CVE website or share:
Arista Added as CVE Numbering Authority (CNA)
Axis Added as CVE Numbering Authority (CNA)
DeepSurface Security Added as CVE Numbering Authority (CNA)
Environmental Systems Research Institute Added as CVE Numbering Authority (CNA)
Mautic Added as CVE Numbering Authority (CNA)
NEC Corporation Added as CVE Numbering Authority (CNA)
Octopus Deploy Added as CVE Numbering Authority (CNA)
Simplinx Added as CVE Numbering Authority (CNA)
Synopsys Added as CVE Numbering Authority (CNA)
Vaadin Added as CVE Numbering Authority (CNA)
Xen Project Added as CVE Numbering Authority (CNA)
Xylem Added as CVE Numbering Authority (CNA)
Zoom Added as CVE Numbering Authority (CNA)
Our CVE Story: An Open-Source, Community-Based Example
Guest author Mark Cox of Apache Software Foundation has been a CVE Board Member since 2002 and Apache Software Foundation is a CNA.
Several CVE Numbering Authorities (CNAs) have contributed to the “Our CVE Story” blog series on the CVE website. The intention is to educate, anticipate questions, and encourage others to become part of the CVE community. While some CNAs may be more or less similar, each CNA is unique, a little bit different from the others.
The Apache Software Foundation (ASF) has partnered with the CVE Program as a CNA since August 19, 2016. ASF is the world’s largest open-source foundation with over 350 individual projects and thousands of committers. Every Apache project is managed separately, by different people who are all volunteers, including the security teams. Their processes vary, with the foundation only having a few hard requirements on the processes, mostly around creating releases and handling security issues. As you can imagine, that creates some interesting challenges for being a CNA.
In 2020, our security team received over 18,000 emails from which we investigated nearly 1,000 potential vulnerability reports. ASF processes are heavily focused around email so we utilize shared Gmail mailboxes and extensive use of labels for handling incoming security issues with a GTD (Getting Things Done) methodology. Once an issue has been confirmed and accepted by a project, they contact the security team, and we assign appropriate CVE IDs. For 2020, we assigned CVE IDs to 151 issues. More statistics and details of the noteworthy vulnerability events of 2020 can be seen here.
We have a default policy for handling security issues for all ASF projects, which includes ensuring everything that is a security vulnerability in a release is assigned a CVE ID, no matter the severity or if it was found internally or externally, and a common process for disclosures. Until recently, the process required each project to create their own security advisory text and, once an issue is public, submit the CVE Record details to the CVE Program themselves. The security team would allocate names to projects on request from a single ASF pool allocated by the CVE Program. For some projects that only handle one or two issues a year, this was quite a burden to have to learn the right process and formats, and it led to mistakes being made and sometimes fairly substantial delays in getting the CVE Records published.
Our goal then was to eliminate these delays, to get the CVE List updated within a day or less of an issue being published by a project, and to add as much automation as possible. Demands on our project’s security and development teams should be minimal and we should reduce the overheads and cumbersome processes for projects. We want our projects to see handling security issues as something that is easy rather than something they want to avoid.
Our first step towards our goal of simplification and efficiency was to provide a way for projects to capture information about vulnerabilities in a common format we could easily submit to the CVE Program. We started with the Vulnogram tool, hosting a heavily modified version internally and hooking it into the ASF OAuth system used to authenticate our committers. This allows projects to get an overview of all the issues they are currently handling and provides a structured way for them to enter the vulnerability data and generate the advisories and email formats needed by our policy.
The CVE Program’s Automation Working Group (AWG) is the community at work to design, develop and deploy automated capabilities that support the efficient management of the CVE Program. We joined the test group in the AWG to be able to use their new CNA API and made changes to Vulnogram to support it. To that end, we became the first CNA to use the CVE request API to allocate a live CVE ID, so now the ASF security team can use the web tool to allocate a CVE ID for a project and create the vulnerability document ready for them to fill in.
Once a project sets the state of an issue to “public”, it sends a notification to the security team. The security team then uses the JSON format to submit a pull request to the cveproject git repo. The pull request usually gets approved within a few hours, with the CVE website updated soon after.
Going forward, we hope to be a part of the continued collaborative improvement of the program through automation. Some of our future goals include leveraging future APIs to allow us to submit the vulnerability data in JSON format directly from our tool. We are also planning a hybrid approach where we have a set of projects that have been trained on the correct allocation of CVE IDs and will be able to complete all the steps from requesting a CVE ID through to submission all by themselves. Other projects, those that rarely use the process, will get more guidance and review from the security team.
We’ve also just started using the JSON data to generate automated advisory pages for one project, the Apache HTTP Server, and will look at extending this to others too.
Another part of our goal in doing this work is to use the knowledge from our experiences as a bigger CNA to provide feedback to the CVE community. We think this experience and knowledge can help others.
In conclusion, we’re rapidly embracing the recent CVE Program innovations that make the process of handling CVE IDs faster and more efficient. We’re excited by the future prospects that can make handling of security issues less cumbersome, faster, and lightweight. This will not only benefit our projects by freeing up time for our all-volunteer members, but also the users of our projects by ensuring vulnerability information is updated and available quickly and consistently.
Mark J. Cox
VP of Security
Apache Software Foundation
Comments or Questions?
If you have any questions about this article, please comment on the CVE Blog on Medium or use the CVE Request Web Form and select “Other” from the dropdown menu to contact the CVE Program. We look forward to hearing from you!
Read on CVE website or share on Medium:
Our CVE Story: An Open-Source, Community-Based Example, CVE Blog
Our CVE Story: An Open-Source, Community-Based Example, Medium
My CVE Story: How I Became the CVE Program’s First Vulnerability Researcher CNA
Guest author Larry W. Cashdollar is a vulnerability researcher and the CVE Program’s first independent researcher CNA.
I discovered my first vulnerability in 1999. By that point, I had been involved in computer security since late 1994, working as a consultant at the now defunct netMaine consulting company. My days then consisted of tracking new vulnerabilities posted on Bugtraq and collecting exploits that we would catalog and possibly use during our penetration testing engagements. I remember talking with my co-worker about how people would find vulnerabilities; how did they know what to look for and where to look?
In 1998, better opportunities led me to apply for a UNIX Administrator position at Computer Science Corporation. This position gave me access to over 3,000 assorted UNIX systems, ranging from HP-UX to SGI IRX to IBM AIX. On my first day, my new manager took me to the SGI lab, which was a room with 8-10 SGI Indigo/2 workstations. My manager then told me he’d give me a login once I proved my worth. I knew from being in security and studying various UNIX vulnerabilities for a few years that SGI IRIX had a passwordless IP account, so I simply walked up to one of the workstations, typed IP into the login prompt, and hit enter. When my manager saw that I was able to logon to the SGI, he immediately offered me a job in security.
I spent the next few months testing the security of many various UNIX servers. We had a datacenter that I, as a UNIX Administrator, was not able to access; only the level III UNIX Administrators were allowed access. The data center housed a refrigerator-sized $250,000 SGI ONYX/2. The administrators who had access to the datacenter would routinely taunt my team about how they have root access to the ONYX/2 and we didn’t, almost weekly. I had taken it upon myself to hack root on the ONYX/2. I knew I could get a shell using the lP login, but I didn’t know of any zero-days to elevate my privileges to root. What I needed was another system with the same OS version that I could examine. I did have access to another SGI box with the same OS, an Indigo/2 workstation that no one used.
To elevate my privileges, I started looking at setuid root binaries. The term setuid means the program, when executed by a regular user, runs with superuser privileges. I noticed a binary named /usr/sbin/midikeys that, when executed, popped up a little piano keyboard on my screen. I wondered why a piano application would need to run as root, so I started toying with it. It had a feature that would allow you to save and edit music files, so I tried to open /etc/passwd (where all the user accounts’ passwords are stored) to add my own superuser entry. It worked! So, logged into the ONYX/2 as IP, I used my newly found zero-day to modify the password file and added ‘larry’ as a new root-level account. I logged into my new ‘larry’ account with superuser (root) privileges and started looking around. I attempted to change my account password to something besides a blank password and realized I was changing the root account’s password. I had accidentally changed the root password to ‘ctrl ^D’ in an attempt to back out of my command. I knew the system administrators of the ONYX would be pretty angry with me, so I asked my good friend Donovan to tell the ONYX system administrator what I had done. At the exact time I was doing this, the sysadmin was demonstrating the SGI's 3-D modeling abilities to a group of officials, including a Navy admiral. They were planning on demonstrating the 3D CAD drawings of the Aegis class destroyer ships being designed and built at a major U.S. shipyard. The sysadmin was unable to login and had to scrub the demo.
How I became a CVE Numbering Authority (CNA)
I remember sending the details of my newfound security hole to Bugtraq and being excited when I saw that the CVE Program assigned a CVE ID to the vulnerability after SGI fixed it. As a new researcher, this represented a stamp of approval from folks who had lots of experience in cataloging and validating vulnerabilities.
In 2016, I presented a talk at the DEF CON Wall of Sheep Village that had some CVE Program team members in the audience. I was invited to meet with them to discuss becoming the first vulnerability researcher CNA who could assign CVEs to vulnerabilities that I discovered. In November 2016, I officially partnered with the CVE Program as a CNA.
Since then, I’ve discovered over 300 vulnerabilities and assigned many of the CVE IDs myself. The process has become more and more streamlined over the years, and I hope to remain part of the CNA program as I continue to discover new vulnerabilities in software.
Larry Cashdollar
Vulnerability Researcher
Comments or Questions?
If you have any questions about this article, please comment on the CVE Blog on Medium or use the CVE Request Web Form and select “Other” from the dropdown menu to contact the CVE Program. We look forward to hearing from you!
Read on CVE website or share on Medium:
My CVE Story: How I Became the CVE Program’s First Vulnerability Researcher CNA, CVE Blog
How I Became the CVE Program’s First Vulnerability Researcher CNA, Medium
We Speak CVE Podcast – New Episodes!
The “We Speak CVE” podcast focuses on cybersecurity, vulnerability management, and the CVE Program. Our latest episodes are below:
Partnering with the CVE Program
Shannon Sabens of CrowdStrike speaks with Jo Bazar of the CVE Program, Erin Alexander of CISA ICS, and Tomo Itou of JPCERT/CC about the structure and objectives of the CVE Numbering Authority (CNA) program, what it means to be a Root and a CNA, the benefits of partnering with the CVE Program, and recommendations for organizations considering becoming a Root or CNA.
How MongoDB Manages Its CVEs
Chris Sandulow, Boris Sieklik, and Lena Smart from MongoDB discuss their internal processes for managing CVEs, the importance of CVSS scoring to their customers, the benefits experienced from partnering with the CVE Program as a CVE Numbering Authority (CNA), and recommendations for other organizations considering becoming a CNA.
The podcast is available for free on the CVE website as an MP3 file, on the CVE Program Channel on YouTube, and on major podcast directories such as Spotify, Stitcher, Google Podcasts, iHeartRadio, Podcast Addict, Podchaser, Pocket Casts, Deezer, Listen Notes, Player FM, and Podcast Index, among others.
Please give the podcast a listen and let us know what you think by commenting on the CVE Blog on Medium or use the CVE Request Web Form and select “Other” from the dropdown menu. We look forward to hearing from you!
CVE in the News
Pulse Connect Secure VPN Gateway Has New 'Critical' Vulnerability Under Exploit, Redmond Magazine
SAP issues advisory on the exploit of old vulnerabilities to target enterprise applications, ZDNet
Nvidia Warns: Severe Security Bugs in GPU Driver, vGPU Software, Threatpost
Google Chrome Receives Security Fix Update for Windows, Mac, Linux Devices, Gadgets 360
NAME:WRECK DNS vulnerabilities affect over 100 million devices, BleepingComputer
Keeping Up with CVE
Follow us for the latest from CVE:
@CVEnew - Twitter feed of the latest CVE Records
@CVEannounce - Twitter feed of news and announcements about CVE
CVE-CWE-CAPEC - LinkedIn showcase page
CVE Blog - CVE main website
CVE Blog on Medium - Medium
We Speak CVE - Podcast
CVEProject - GitHub
CVE Documentation - GitHub
CVE Program Channel - YouTube
CVE Announce Newsletter - Email
If this newsletter was shared with you, subscribe by sending an email message to LMS@mitre.org with the following text in the SUBJECT of the message: “subscribe cve-announce-list” (do not include the quote marks). You may also subscribe on the CVE website at https://cve.mitre.org/news/newsletter.html. To unsubscribe, send an email message to LMS@mitre.org with the following text in the SUBJECT of the message “signoff cve-announce-list” (do not include the quote marks).
CVE® is sponsored by the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA). Copyright © 2021, The MITRE Corporation. CVE is a registered trademark and the CVE logo is a trademark of The MITRE Corporation. MITRE maintains CVE and provides impartial technical guidance to the CVE Board, CVE Working Groups, and CVE Numbering Authorities on all matters related to ongoing development of CVE.
