How did Browser Reaper cause browsers to crash?

Security researcher Sabri Haddouche created and released a suite of browser denial-of-service proofs of concept -- dubbed Browser Reaper -- that caused Chrome, Firefox and Safari browsers to freeze or crash. Haddouche notified Mozilla Corp. of the vulnerability behind Browser Reaper, but Mozilla said the bug was a duplicate of a previously reported vulnerability. How do software publishers prioritize patching a bug that it believes has already been reported?

At times, tracking bugs can be nearly as difficult as finding and fixing them. This is in addition to the difficulties of disclosing vulnerabilities, and responsible disclosure can make the process for handling duplicated bugs even more difficult.

Finding a bug may be very hard, but the bug finder doesn't necessarily need to know where in the source code or executable the vulnerability is located. This is something software developers absolutely need to know to determine an appropriate fix for the bug.

Likewise, developers may need to find all of the instances of the vulnerable code and, with any luck, fix any bugs that weren't found initially. This may involve looking into dependencies within the code, the libraries used or other similar functions in the code. It also may expand further than just one bug, as all of this takes time and resources.

When vulnerabilities are actively being exploited by an attacker, time may be of the essence to prevent additional systems from being compromised. Therefore, assessing the overall risk of a vulnerability is critical to prioritize fixing it. In some cases, a denial-of-service (DoS) attack can lead to a remote code execution vulnerability, so bugs that pose further risks should be prioritized. For low-priority vulnerabilities or vulnerabilities with similar characteristics, bugs may need to wait to be fixed based on a company's software development methodology and available resources.

Security researcher Sabri Haddouche reported a bug in Firefox -- Browser Reaper -- that saw many of these factors come into play in terms of fixing a DoS vulnerability. The bug was found when a webpage initiated a file download that had an extremely long name and caused the web browser to crash.

The bug report covered investigation into similar bugs, interaction with the parent process and how URLs should be handled. Based on the developer's analysis, the bug was classified as a duplicate of another bug and, as such, it was considered a low-priority fix.

Ask the expert:
Have a question about enterprise threats? Send it via email today. (All questions are anonymous.)