Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 8 Aug 2020 07:21:35 -0500
From: Daniel Ruggeri <>
Subject: Re: CVE-2020-11984: Apache httpd: mod_uwsgi buffer

On 8/7/2020 8:20 PM, Seth Arnold wrote:
> On Fri, Aug 07, 2020 at 06:31:38AM -0500, Daniel Ruggeri wrote:
>> CVE-2020-11984: mod_uwsgi buffer overlow
>> Versions Affected:
>> httpd 2.4.32 to 2.4.44
>> Description:
>> Apache HTTP Server 2.4.32 to 2.4.44
>> mod_proxy_uwsgi info disclosure and possible RCE
>> References:
> Hello Daniel, all,
> I'm confused: this english description of affected versions
> reads like 2.4.44 is affected. However, there is a heading on the
> vulnerabilities_24.html page that says this CVE is fixed in 2.4.44.
Hi, Seth;

   You're correct. That was an error on our part. We try to double check
this data (since sometimes we burn a release number as we test the
candidate) and things can get out of sync. I have it in my personal TODO
list to add some tooling around automating this particular part of the
release management process.

I've fixed this in a recent patch and the the site should now show the
correct data - many thanks for the correction

> Many projects include a "fixed in versions ..." list to indicate when
> something is fixed; I think this is less ambiguous.
> The "affects versions" don't always line up with the heading that claims
> to be fixed, eg CVE-2019-10092 claims to be fixed in 2.4.41, but the
> Affects entry doesn't mention 2.4.40.

Right - sometimes this will happen when we don't release a version. This
particular example is because 2.4.40 was not released (see below for a
bit more info).

> The headings are out of order:
> $ curl -sq | grep "Fixed in Apache"
> Fixed in Apache httpd 2.4.44</h1><dl>
> Fixed in Apache httpd 2.4.25</h1><dl>  # 2.4.25 is between 2.4.42 and 2.4.44
> Fixed in Apache httpd 2.4.42</h1><dl>
> Fixed in Apache httpd 2.4.41</h1><dl>
> Fixed in Apache httpd 2.4.39</h1><dl>
> [..]

No problem - I thought about this as I was putting together the
announcement but didn't adjust it at the time. I've fixed this as well

> The download site doesn't have a 2.4.40 download:
> But the CHANGES_2.4.41 file shows a 2.4.40 release:

Correct - 2.4.40 was not released. We made a number of changes leading
up to it, but ultimately found an issue in the release candidate that we
fixed between then and a release that we were comfortable with.

If you're interested, you can see a bit more history (and even what's
coming in future release) by taking a look at this file:

We always note when we tag a release and then the final release date for
every version. You can find similar files for the old 2.2, 2.0, and 1.3
branches too.

> I don't actually care that much about CVE-2019-10092 -- I just tried to
> figure out the status of CVE-2020-11984 by looking at other examples on
> the page and found the page difficult to understand.
> And, something is a bit off with the CURRENT-IS-$version markers:
> $ curl -sq | grep -c CURRENT
> 47
I can see how that appears odd. This URL is our archive distribution
point, so anything we release to the formal distribution point will be
added here automatically to preserve history. It's best to use the
current distribution point:

We always maintain the zero-length CURRNT-IS-foo file here and remove
non-current releases.

> I expected one in each of the 2.0, 2.2, and 2.4 series, or perhaps just
> one for the newest 2.4 release.
> Thanks

Thanks for taking the time to provide feedback! Have a great weekend

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.