CVE 2016 4979

#####The Apache HTTP Server 2.4.18 through 2.4.20, when mod_http2 and mod_ssl are enabled, does not properly recognize the "SSLVerifyClient require" directive for HTTP/2 request authorization, which allows remote attackers to bypass intended access restrictions by leveraging the ability to send multiple requests over a single connection and aborting a renegotiation.#####

1. The fix commit for the vulnerability (a git hash)

   • 2d0e4eff04ea963128a41faaef21f987272e05a2

2. The commit that introduced the vulnerability (a git hash)

   • 75b798dfa0667dda4ef0309b24a34fd2a3485351

3. A description of the coding mistake that led to the vulnerability

   • The request causes renegotiation on a slave connection. This is not allowed since there might be concurrent requests on the connection. Additionally, due to failure to reset the SSL verifications on failure, concurrent requests could bypass a failure which should be prevented and still run.

4. Who found it?

   • Erki Aring of Liewenthal Electronics

5. Who fixed it? (Try to get some information on people beyond their name and email)

   • Erki Aring and Stefan Eissing, author of the official http/2 apache plugin

6. Is this code tested by automated tests?

   • Unclear, assumed no.

7. Was it the same people who found it the ones who fixed it?

   • Yes: Erki Aring is credited with the fix, though Stefan Eissing applied it.

• Read the discussions about the code between introduction and fix. What are the discussions like? Are people discussion requirements, design, security, compatibility, etc? The more you can tie their discussion into the software development process the better. And, again, give me dates and links to actual mailing list discussions. Are there any other linguistic features you notice about these discussions? (e.g. are people angry or polite? terse, or ranty? is there some jargon you notice?)

  • Discussions are civil and generally focused on work. Relevant dates are focused on the beginning of July 2016. The discussion is centered on voting in the patch (2.4.23) containing the fix to this vulnerability. Also noteworthy is a discussion from early May which could be have been the original source of what ultimately became this vulnerability.

• Was there a bounty awarded?

  • No

• Any evidence of exploit? Was there a metasploit module made for it, or another exploit related to this (https://www.metasploit.com/).

  • There are 2 results for this CVE vulnerability on metasploit but neither have exploit modules. There has been no other records of exploits, and since the initial fix was the same day it was reported, an exploit in that time is somewhat unlikely.

• Any mention of how it was found? Fuzzer? Manual?

  • No mention, but given how the person who found it was a third party it is likely manual

• Any other significant project-level development events happen during this time? (e.g. dump a related dependency, or change the design in some way)

  • There were no major developments happening at this time. Indeed the mailing list was entirely silent for over a week prior to the discovery of the vulnerability, meaning there was likely not much happening in the system.

• Any other interesting facts about this vulnerability that you would tell someone. Think of yourself as a journalist who is getting a a story together

  • It would appear that discussions about patching http/2 to better handle stream resets began on May 4th, in a communication posted by Michael Kaufmann, though no action appeared to be taken. The vulnerability was presented to Apache on June 30th and was patched on the same day. Early on July 1st, the version containing this fix was released. There were no public communications aside from the vote to release relevant to the patch.