• CNA
• Response

Response Guide

The glibc security team rotates the active member in a round-robin fashion from security issue report to report in an attempt to balance the workload and to give each member an opportunity to practice the process.

The active member is responsible for taking a security issue report and moving it through the stages of the process.

All members of the security team should:

• Review reports sent to glibc-cna private mailing list.
• Review reports sent only to them and guide the reporter to submit to the glibc-cna private mailing list.

The active security member should:

• Write up an initial response to the report
  • The response should indicate if the issue is considered a security issue or not.
  • If the issue is not a security issue then it should be clear why and how the project security policy was used to arrive at this decision.

• If the issue was deemed a security issue then a CVE ID should be reserved for the issue using the command cve reserve

  • The CVE ID should be communicated with the reporter.
• Consensus should be reached with the reporter if the issue should be under embargo.
  • An issue is generally placed under embargo when there is a PoC that shows existing applications can be exploited.
  • An initial embargo timeline should be discussed with the reporter.
• Work with developers to get the solution, patch or workaround ready.
  • Identify vulnerable commit.

  • Help developers write the security advisories that go into advisories/

  • Help developers write a patch and test for the issue.
  • Having this ready helps support the next steps as we notify linux-distros (embargoed issues) or oss-security (public issues).

• The linux-distros or oss-security (already public) list should be notified

  • A semi-detailed security advisory writuep should be sent to the appropriate list with enough information for the distributions to take action.
  • The list should be informed that the CNA does not assign CVSS scores and leaves that up to the downstream deployments.
• Work with the reporter to expand disclosure to project developers who will help formulate a solution for the vulnerability (if not already developed).
• Push patches into all the active branches to fix the issue including the main development branch.
  • Note: If the git repo access is down then we should not disclose.

• Push an update to the advisories/ to create the advisory file with all fixed commits listed.

  • Generate the fixed list of commits: git log --pretty=oneline --all --grep=f9dc609e06b1136bb0408be9605ce7973a767ada | awk '{printf("Fix-Commit: %s\n", $1)}'

  • Make sure the list is in order of newest to oldest release.
  • The advisory file must have a first paragraph that is comprehensive and succint since it will be used in the CVE database update.
• Update the CVE information in the CVE database.

  • Use Vulnogram to create the CVE v5 JSON.

  • Requires link to the git advisory file that was created in the previous step.

• Publish the advisory text to libc-announce@sourceware.org and oss-security@lists.openwall.com e.g. The GNU C Library security advisories update for 2024-02-30

  • Publish the generated CVE v5 JSON to the MITRE database using the command: cve publish CVE-YYYY-NNNN CVE-YYYY-NNNN.json

The rest of the security team should:

• Support the current active team member with any help they need e.g. analysis, review, testing.
• Be prepared to become the active team member when the next report arrives.