[v2] Move CVE information into advisories directory
Checks
| Context |
Check |
Description |
| redhat-pt-bot/TryBot-apply_patch |
success
|
Patch applied to master at the time it was sent
|
| redhat-pt-bot/TryBot-32bit |
success
|
Build for i686
|
| linaro-tcwg-bot/tcwg_glibc_build--master-arm |
success
|
Testing passed
|
| linaro-tcwg-bot/tcwg_glibc_build--master-aarch64 |
success
|
Testing passed
|
| linaro-tcwg-bot/tcwg_glibc_check--master-arm |
success
|
Testing passed
|
| linaro-tcwg-bot/tcwg_glibc_check--master-aarch64 |
success
|
Testing passed
|
Commit Message
One of the requirements to becoming a CVE Numbering Authority (CNA) is
to publish advisories. Do this by maintaining a file for each CVE fixed
in the advisories directory in the source tree. Links to the advisories
can then be shared as:
https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=advisories/GLIBC-SA-YYYY-NNNN
The file format at the moment is rudimentary and derives from the git
commit format, i.e. a subject line and a potentially multi-paragraph
description and then tags to describe some meta information. This is a
loose format at the moment and could change as we evolve this.
Also add a script process-fixed-cves.sh that processes these advisories
and generates a list to add to NEWS at release time.
Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
---
Changes from v1:
- The advisory files now have GLIBC-SA- numbers that the glibc project
can use independently of Mitre.
- Version and release numbers are now gleaned from version.h and
include/features.h instead of tag munging.
- Check for existence of advisories as a directory.
- The format generated by process-fixed-cves.sh is modified to
accommodate GLIBC-SA-* numbers.
- Port all CVEs assigned in 2023 to assign corresponding GLIBC-SA-*
numbers.
Release process changes:
- Auto-generate CVE list from the advisory files to add to NEWS at
release time.
- Replace the advisories directory with a file containing a link to the
advisories directory on gitweb just before tagging. Reinstate the
directory right after opening master for development.
NEWS | 24 +++++---------------
advisories/GLIBC-SA-2023-0001 | 15 +++++++++++++
advisories/GLIBC-SA-2023-0002 | 14 ++++++++++++
advisories/GLIBC-SA-2023-0003 | 11 ++++++++++
advisories/GLIBC-SA-2023-0004 | 13 +++++++++++
advisories/GLIBC-SA-2023-0005 | 11 ++++++++++
scripts/process-fixed-cves.sh | 41 +++++++++++++++++++++++++++++++++++
7 files changed, 110 insertions(+), 19 deletions(-)
create mode 100644 advisories/GLIBC-SA-2023-0001
create mode 100644 advisories/GLIBC-SA-2023-0002
create mode 100644 advisories/GLIBC-SA-2023-0003
create mode 100644 advisories/GLIBC-SA-2023-0004
create mode 100644 advisories/GLIBC-SA-2023-0005
create mode 100755 scripts/process-fixed-cves.sh
Comments
* Siddhesh Poyarekar:
> Also add a script process-fixed-cves.sh that processes these advisories
> and generates a list to add to NEWS at release time.
I would appreciate a Python script for this in case we need to add
word-wrapping etc., but we can make the switch at a later date.
> diff --git a/advisories/GLIBC-SA-2023-0005 b/advisories/GLIBC-SA-2023-0005
> new file mode 100644
> index 0000000000..c094370c5a
> --- /dev/null
> +++ b/advisories/GLIBC-SA-2023-0005
> @@ -0,0 +1,11 @@
> +getaddrinfo: DoS due to memory leak
> +
> +The fix for CVE-2023-4806 introduced a memory leak when an application
> +calls getaddrinfo for AF_INET6 with AI_CANONNAME, AI_ALL and AI_V4MAPPED
> +flags set.
> +
> +CVE-Id: CVE-2023-5156
> +Public-date: 2023-09-25
> +Vulnerable-since: 973fe93a5675c42798b2161c6f29c01b0e243994
> +Fixed-by: ec6b95c3303c700eb89eebeda2d7264cc184a796
> +Fixed-releases: 2.34, 2.35, 2.36, 2.37, 2.38, 2.39
It's confusing that there is no First-vulnerabile-release: here. That's
because it's a 2.39 regression that was fixed during 2.39 development,
before the 2.39 release. So listing 2.39 under fixed releases is
somewhat confusing.
Can we switch to something like this instead?
Vulnerable-Commit: 973fe93a5675c42798b2161c6f29c01b0e243994 (pre-2.39)
Fix-Commit: ec6b95c3303c700eb89eebeda2d7264cc184a796 (pre-2.39)
Vulnerable-Backport: e09ee267c03e3150c2c9ba28625ab130705a485e (2.34)
Vulnerable-Backport: e3ccb230a961b4797510e6a1f5f21fd9021853e7 (2.35)
Vulnerable-Backport: a9728f798ec7f05454c95637ee6581afaa9b487d (2.36)
Vulnerable-Backport: 6529a7466c935f36e9006b854d6f4e1d4876f942 (2.37)
Vulnerable-Backport: 00ae4f10b504bc4564e9f22f00907093f1ab9338 (2.38)
Fix-Backport: 8006457ab7e1cd556b919f477348a96fe88f2e49 (2.34)
Fix-Backport: 17092c0311f954e6f3c010f73ce3a78c24ac279a (2.35)
Fix-Backport: 856bac55f98dc840e7c27cfa82262b933385de90 (2.36)
Fix-Backport: 4473d1b87d04b25cdd0e0354814eeaa421328268 (2.37)
Fix-Backport: 5ee59ca371b99984232d7584fe2b1a758b4421d3 (2.38)
In most cases, we wouldn't have Vulnerable-Backport: lines hopefully.
So the version number would really be a comment that you should ignore
when consuming this data. It can also handle the case of multiple
fixing commits and avoid unclarity about what exactly needs to be
backported.
Do you think it would be to onerous to gather the commit IDs? Something
like this
git log --pretty=oneline --grep ec6b95c3303c700eb89eebeda2d7264cc184a796 release/2.3{4..8}/master
seems to work reasonably well, though.
Thanks,
Florian
On 2023-12-07 11:30, Florian Weimer wrote:
> * Siddhesh Poyarekar:
>
>> Also add a script process-fixed-cves.sh that processes these advisories
>> and generates a list to add to NEWS at release time.
>
> I would appreciate a Python script for this in case we need to add
> word-wrapping etc., but we can make the switch at a later date.
Ack.
>
>> diff --git a/advisories/GLIBC-SA-2023-0005 b/advisories/GLIBC-SA-2023-0005
>> new file mode 100644
>> index 0000000000..c094370c5a
>> --- /dev/null
>> +++ b/advisories/GLIBC-SA-2023-0005
>> @@ -0,0 +1,11 @@
>> +getaddrinfo: DoS due to memory leak
>> +
>> +The fix for CVE-2023-4806 introduced a memory leak when an application
>> +calls getaddrinfo for AF_INET6 with AI_CANONNAME, AI_ALL and AI_V4MAPPED
>> +flags set.
>> +
>> +CVE-Id: CVE-2023-5156
>> +Public-date: 2023-09-25
>> +Vulnerable-since: 973fe93a5675c42798b2161c6f29c01b0e243994
>> +Fixed-by: ec6b95c3303c700eb89eebeda2d7264cc184a796
>> +Fixed-releases: 2.34, 2.35, 2.36, 2.37, 2.38, 2.39
>
> It's confusing that there is no First-vulnerabile-release: here. That's
> because it's a 2.39 regression that was fixed during 2.39 development,
> before the 2.39 release. So listing 2.39 under fixed releases is
> somewhat confusing.
Yeah, I kinda struggled with that and left it unaddressed.
> Can we switch to something like this instead?
>
> Vulnerable-Commit: 973fe93a5675c42798b2161c6f29c01b0e243994 (pre-2.39)
> Fix-Commit: ec6b95c3303c700eb89eebeda2d7264cc184a796 (pre-2.39)
> Vulnerable-Backport: e09ee267c03e3150c2c9ba28625ab130705a485e (2.34)
> Vulnerable-Backport: e3ccb230a961b4797510e6a1f5f21fd9021853e7 (2.35)
> Vulnerable-Backport: a9728f798ec7f05454c95637ee6581afaa9b487d (2.36)
> Vulnerable-Backport: 6529a7466c935f36e9006b854d6f4e1d4876f942 (2.37)
> Vulnerable-Backport: 00ae4f10b504bc4564e9f22f00907093f1ab9338 (2.38)
> Fix-Backport: 8006457ab7e1cd556b919f477348a96fe88f2e49 (2.34)
> Fix-Backport: 17092c0311f954e6f3c010f73ce3a78c24ac279a (2.35)
> Fix-Backport: 856bac55f98dc840e7c27cfa82262b933385de90 (2.36)
> Fix-Backport: 4473d1b87d04b25cdd0e0354814eeaa421328268 (2.37)
> Fix-Backport: 5ee59ca371b99984232d7584fe2b1a758b4421d3 (2.38)
>
> In most cases, we wouldn't have Vulnerable-Backport: lines hopefully.
It's wordy, but I suppose we could bank on it being a rare case.
>
> So the version number would really be a comment that you should ignore
> when consuming this data. It can also handle the case of multiple
> fixing commits and avoid unclarity about what exactly needs to be
> backported.
>
> Do you think it would be to onerous to gather the commit IDs? Something
> like this
>
> git log --pretty=oneline --grep ec6b95c3303c700eb89eebeda2d7264cc184a796 release/2.3{4..8}/master
>
> seems to work reasonably well, though.
That ought to work. I'll add a little README as a separate commit with
some advice on creating these advisories. Do you mind if I add your
Vulnerable-Backport+Fix-Backport suggestion and push this? I want to
file the CNA registration this week so that we have some hope of getting
the CNA up (and announced in NEWS) for 2.39.
Thanks,
Sid
* Siddhesh Poyarekar:
>> So the version number would really be a comment that you should
>> ignore
>> when consuming this data. It can also handle the case of multiple
>> fixing commits and avoid unclarity about what exactly needs to be
>> backported.
>> Do you think it would be to onerous to gather the commit IDs?
>> Something
>> like this
>> git log --pretty=oneline --grep
>> ec6b95c3303c700eb89eebeda2d7264cc184a796 release/2.3{4..8}/master
>> seems to work reasonably well, though.
>
> That ought to work. I'll add a little README as a separate commit
> with some advice on creating these advisories. Do you mind if I add
> your Vulnerable-Backport+Fix-Backport suggestion and push this? I
> want to file the CNA registration this week so that we have some hope
> of getting the CNA up (and announced in NEWS) for 2.39.
I suppose we could do post-commit review for this because it's not code?
So please go ahead if it's time-critical.
Thanks,
Florian
@@ -75,25 +75,11 @@ Changes to build and runtime requirements:
Security related changes:
- CVE-2023-4527: If the system is configured in no-aaaa mode via
- /etc/resolv.conf, getaddrinfo is called for the AF_UNSPEC address
- family, and a DNS response is received over TCP that is larger than
- 2048 bytes, getaddrinfo may potentially disclose stack contents via
- the returned address data, or crash.
-
- CVE-2023-4806: When an NSS plugin only implements the
- _gethostbyname2_r and _getcanonname_r callbacks, getaddrinfo could use
- memory that was freed during buffer resizing, potentially causing a
- crash or read or write to arbitrary memory.
-
- CVE-2023-5156: The fix for CVE-2023-4806 introduced a memory leak when
- an application calls getaddrinfo for AF_INET6 with AI_CANONNAME,
- AI_ALL and AI_V4MAPPED flags set.
-
- CVE-2023-4911: If a tunable of the form NAME=NAME=VAL is passed in the
- environment of a setuid program and NAME is valid, it may result in a
- buffer overflow, which could be exploited to achieve escalated
- privileges. This flaw was introduced in glibc 2.34.
+The following CVEs were fixed in this release, details of which can be
+found in the advisories directory of the release tarball:
+
+ [The release manager will add the list generated by
+ scripts/process-fixed-cves.sh just before the release.]
The following bugs are resolved with this release:
new file mode 100644
@@ -0,0 +1,15 @@
+printf: incorrect output for integers with thousands separator and width field
+
+When the printf family of functions is called with a format specifier
+that uses an <apostrophe> (enable grouping) and a minimum width
+specifier, the resulting output could be larger than reasonably expected
+by a caller that computed a tight bound on the buffer size. The
+resulting larger than expected output could result in a buffer overflow
+in the printf family of functions.
+
+CVE-Id: CVE-2023-25139
+Public-date: 2023-02-02
+Vulnerable-since: e88b9f0e5cc50cab57a299dc7efe1a4eb385161d
+First-vulnerable-release: 2.37
+Fixed-by: c980549cc6a1c03c23cc2fe3e7b0fe626a0364b0
+Fixed-releases: 2.37, 2.38
new file mode 100644
@@ -0,0 +1,14 @@
+getaddrinfo: Stack read overflow in no-aaaa mode
+
+If the system is configured in no-aaaa mode via /etc/resolv.conf,
+getaddrinfo is called for the AF_UNSPEC address family, and a DNS
+response is received over TCP that is larger than 2048 bytes,
+getaddrinfo may potentially disclose stack contents via the returned
+address data, or crash.
+
+CVE-Id: CVE-2023-4527
+Public-date: 2023-09-12
+Vulnerable-since: f282cdbe7f436c75864e5640a409a10485e9abb2
+First-vulnerable-release: 2.36
+Fixed-by: bd77dd7e73e3530203be1c52c8a29d08270cb25d
+Fixed-releases: 2.36, 2.37, 2.38, 2.39
new file mode 100644
@@ -0,0 +1,11 @@
+getaddrinfo: Potential use-after-free
+
+When an NSS plugin only implements the _gethostbyname2_r and
+_getcanonname_r callbacks, getaddrinfo could use memory that was freed
+during buffer resizing, potentially causing a crash or read or write to
+arbitrary memory.
+
+CVE-Id: CVE-2023-4806
+Public-date: 2023-09-12
+Fixed-by: 973fe93a5675c42798b2161c6f29c01b0e243994
+Fixed-releases: 2.34, 2.35, 2.36, 2.37, 2.38, 2.39
new file mode 100644
@@ -0,0 +1,13 @@
+tunables: local privilege escalation through buffer overflow
+
+If a tunable of the form NAME=NAME=VAL is passed in the environment of a
+setuid program and NAME is valid, it may result in a buffer overflow,
+which could be exploited to achieve escalated privileges. This flaw was
+introduced in glibc 2.34.
+
+CVE-Id: CVE-2023-4911
+Public-date: 2023-10-03
+Vulnerable-since: 2ed18c5b534d9e92fc006202a5af0df6b72e7aca
+First-vulnerable-release: 2.34
+Fixed-by: 1056e5b4c3f2d90ed2b4a55f96add28da2f4c8fa
+Fixed-releases: 2.34, 2.35, 2.36, 2.37, 2.38, 2.39
new file mode 100644
@@ -0,0 +1,11 @@
+getaddrinfo: DoS due to memory leak
+
+The fix for CVE-2023-4806 introduced a memory leak when an application
+calls getaddrinfo for AF_INET6 with AI_CANONNAME, AI_ALL and AI_V4MAPPED
+flags set.
+
+CVE-Id: CVE-2023-5156
+Public-date: 2023-09-25
+Vulnerable-since: 973fe93a5675c42798b2161c6f29c01b0e243994
+Fixed-by: ec6b95c3303c700eb89eebeda2d7264cc184a796
+Fixed-releases: 2.34, 2.35, 2.36, 2.37, 2.38, 2.39
new file mode 100755
@@ -0,0 +1,41 @@
+#!/bin/bash -e
+# Copyright The GNU Toolchain Authors.
+# This file is part of the GNU C Library.
+#
+# The GNU C Library is free software; you can redistribute it and/or
+# modify it under the terms of the GNU Lesser General Public
+# License as published by the Free Software Foundation; either
+# version 2.1 of the License, or (at your option) any later version.
+#
+# The GNU C Library is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+# Lesser General Public License for more details.
+#
+# You should have received a copy of the GNU Lesser General Public
+# License along with the GNU C Library; if not, see
+# <https://www.gnu.org/licenses/>.
+
+if ! [ -d advisories ]; then
+ echo "error: Run me from the toplevel directory of the glibc repository."
+ exit 1
+fi
+
+release=$(echo RELEASE | gcc -E -include version.h -o - - | grep -v "^#")
+minor=$(echo __GLIBC_MINOR__ | gcc -E -include include/features.h -o - - |
+ grep -v "^#")
+
+if [ $release = "\"development\"" ]; then
+ cur_rel=2.$((minor + 1))
+else
+ cur_rel=2.$minor
+fi
+
+for f in $(grep -l "^Fixed-releases: .*$cur_rel.*" advisories/*); do
+ echo -e " $(basename $f):"
+ cve_id=$(sed -n 's/CVE-Id: \(.*\)/\1/p' $f)
+ echo "$(head -1 $f) ($cve_id)" | fold -w 68 -s | while read line; do
+ echo " $line"
+ done
+ echo
+done