Maksim Kabakou - Fotolia
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.)
Dig Deeper on Web server threats and application attacks
Related Q&A from Nick Lewis
Enterprises have many options for email security best practices, ranging from deploying email security protocols to educating end users on the ... Continue Reading
Cyberattacks often begin with a port scan attack, which attackers use to find exploitable vulnerabilities on targeted systems. Learn how they work ... Continue Reading
Monitoring process memory is one way to combat fileless malware attacks. Here's what you can do to protect your network against these campaigns. Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.