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:02:21 -0500
From: Daniel Ruggeri <>
To: Solar Designer <>
 HTTPD Security <>
Subject: Re: CVE-2020-11984: Apache httpd: mod_uwsgi buffer

Hi, Alexander;

On 8/7/2020 7:54 AM, Solar Designer wrote:
> Hi Daniel,
> On Fri, Aug 07, 2020 at 06:31:38AM -0500, Daniel Ruggeri wrote:
>> CVE-2020-11984: mod_uwsgi buffer overlow
>> Severity: moderate
>> Vendor: The Apache Software Foundation
>> 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
>> Mitigation:
>> disable mod_uwsgi
> You appear to use mod_uwsgi and mod_proxy_uwsgi interchangeably in the
> above, but I guess they're actually different modules?
Yes, you're correct. There is a mod_uwsgi maintained elsewhere in the
wild. This one was a typo that had made its way into the description.
>> Credit:
>> Discovered by Felix Wilhelm of Google Project Zero
>> References:
> The vulnerability description at that link mentions mod_proxy_uwsgi
> only, so I guess it's the one affected module, whereas mod_uwsgi is
> unaffected?
> In general, I think you include too little detail in these postings and
> at the link above.  You do include the bare minimum (thanks!), but it is
> unclear from these announcements where in the code the issues are.  You
> could reference source files and function names and/or commits fixing
> the issues.  You could also describe the impact in more detail - e.g.,
> what kind of "info disclosure" (what info is potentially disclosed and
> to where).  I am just using this as an example of how I think you could
> improve reporting on Apache httpd vulnerabilities in general.

Thanks - I've included our security mailing list to pass this feedback
along to the rest of the security group as a heads up. As you can
imagine, with such a strong downstream community from our releases, we
try to be careful so as to not place too much information in the
descriptions to make it trivial to exploit vulnerabilities before those
downstream packagers can incorporate fixes. At the same time, there's
always room for improvement :-)

Have a great weekend!

> Thanks,
> Alexander

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.