[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAAHN_R2jD-CdpMauH+L_pz1mYBiKSD03jh8Azhw8KUFG=f+ytw@mail.gmail.com>
Date: Tue, 3 Oct 2023 15:47:06 -0400
From: Siddhesh Poyarekar <siddhesh.poyarekar@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: CVE-2023-4806, CVE-2023-5156: glibc: potential
use-after-free in getaddrinfo()
On Tue, Oct 3, 2023 at 3:18 PM Solar Designer <solar@...nwall.com> wrote:
> I wish someone more knowledgeable about this specific issue would post
> this, but since no one did, let me do it.
>
> Current upstream glibc NEWS contains these entries:
We're in the process of setting up a glibc CNA, so we will hopefully
send out upstream advisories more regularly once we've got that in
place.
>
> > 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.
>
> Apparently, CVE-2023-4806 has existed for ages, whereas CVE-2023-5156
> only existed for ~10 days last month.
CVE-2023-5156 was a regression from the fix to CVE-2023-4806; we
requested a separate CVE for the benefit of distributions that may
have already released the fix for the first CVE.
>
> Bug 30843 (CVE-2023-4806) - potential use-after-free in getcanonname:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=30843
> https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=973fe93a5675c42798b2161c6f29c01b0e243994
>
> Main upstream commit:
>
> > commit 973fe93a5675c42798b2161c6f29c01b0e243994
> > Author: Siddhesh Poyarekar <siddhesh@...rceware.org>
> > Date: Fri Sep 15 13:51:12 2023 -0400
> >
> > getaddrinfo: Fix use after free in getcanonname (CVE-2023-4806)
> >
> > When an NSS plugin only implements the _gethostbyname2_r and
> > _getcanonname_r callbacks, getaddrinfo could use memory that was freed
> > during tmpbuf resizing, through h_name in a previous query response.
> >
> > The backing store for res->at->name when doing a query with
> > gethostbyname3_r or gethostbyname2_r is tmpbuf, which is reallocated in
> > gethosts during the query. For AF_INET6 lookup with AI_ALL |
> > AI_V4MAPPED, gethosts gets called twice, once for a v6 lookup and second
> > for a v4 lookup. In this case, if the first call reallocates tmpbuf
> > enough number of times, resulting in a malloc, th->h_name (that
> > res->at->name refers to) ends up on a heap allocated storage in tmpbuf.
> > Now if the second call to gethosts also causes the plugin callback to
> > return NSS_STATUS_TRYAGAIN, tmpbuf will get freed, resulting in a UAF
> > reference in res->at->name. This then gets dereferenced in the
> > getcanonname_r plugin call, resulting in the use after free.
> >
> > Fix this by copying h_name over and freeing it at the end. This
> > resolves BZ #30843, which is assigned CVE-2023-4806.
> >
> > Signed-off-by: Siddhesh Poyarekar <siddhesh@...rceware.org>
>
> also backported by upstream to branches all the way back to 2.34, but
> apparently even older are affected.
Yes, I've checked back to 2.28 for rhel-8; in fact that was where I
discovered the bug first and had hoped that my refactor had fixed it
like in case of CVE-2023-4813, but unfortunately it wasn't :/
Thanks,
Sid
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
