Apple Safari 4.0.3/4.0.4 Stack Exhaustion Exploit Explained

What this paper is

This paper describes a Denial of Service (DoS) vulnerability in Apple Safari versions 4.0.3 and 4.0.4 on Windows. The vulnerability is triggered by a JavaScript code snippet that causes the browser to consume excessive amounts of memory, leading to a crash.

Simple technical breakdown

The exploit works by creating a self-replicating JavaScript string. This string is repeatedly concatenated with itself, causing the browser's memory usage to grow exponentially. Eventually, the browser runs out of memory, leading to a crash or freeze, thus achieving a Denial of Service.

Complete code and payload walkthrough

The provided code is a single JavaScript snippet intended to be embedded within an HTML file that Safari would render.

<script>
//Written by: Fredrik Nordberg Almroth
//URL: http://h.ackack.net/
//Affected: Safari 4.0.3 & 4.0.4 - Other versions might be vulnerable aswell.
  a="<script>var b=\"<iframe src='javascript:window.location=\"boom\"'></iframe>\";while(1){b=b+b;document.write(b);}</scr"+"ipt>";
  while(1){
    a=a+a;
    document.write(a);
  }
</script>

Let's break down the code:

1. //Comments: These lines provide author information, a URL, and list the affected versions. They are informational and do not affect the execution.

2. a="<script>var b=\"<iframe src='javascript:window.location=\"boom\"'></iframe>\";while(1){b=b+b;document.write(b);}</scr"+"ipt>";:

   • This line declares a JavaScript variable named a.
   • It assigns a string to a. This string itself contains another JavaScript snippet.
   • The inner JavaScript snippet:
     • Declares a variable b.
     • Assigns a string to b which represents an <iframe> element. The src attribute is set to javascript:window.location="boom". This is a technique to trigger a JavaScript execution within the iframe, which in this context, is designed to do something, though its primary purpose here is to be part of the growing string.
     • while(1){b=b+b;document.write(b);}: This is a loop that continuously concatenates the string b with itself (b=b+b) and then writes the growing string b to the document (document.write(b)). This part is designed to consume memory within the context of the iframe, but the main DoS is orchestrated by the outer loop.
   • The </scr"+"ipt> part is a common obfuscation technique to prevent simple string matching or parsing that might look for the literal </script> tag. It concatenates two strings to form the closing script tag.

3. while(1){ a=a+a; document.write(a); }:

   • This is the main loop that causes the Denial of Service.
   • while(1): This creates an infinite loop.
   • a=a+a;: In each iteration, the string a is concatenated with itself. This means the string a doubles in length with every pass.
   • document.write(a);: The current, increasingly large, string a is written to the HTML document.

Mapping list:

• a="<script>...</scr"+"ipt>";: Initialization of the primary string variable a which contains a nested script.
• var b="...": Declaration of a secondary string variable b within the nested script.
• "<iframe src='javascript:window.location=\"boom\"'></iframe>": The content of variable b, an iframe tag designed to execute JavaScript.
• while(1){b=b+b;document.write(b);}: The inner loop that attempts to exhaust memory by duplicating b and writing it.
• while(1){ a=a+a; document.write(a); }: The outer, primary loop that exponentially grows the string a and writes it to the document, causing the main memory exhaustion.

Complete code and payload walkthrough

The provided code is entirely JavaScript, intended to run within a web browser. There is no separate "shellcode" or "payload" in the traditional sense of executable binary code. The "payload" is the JavaScript itself, and its "execution" is the browser's interpretation and rendering of this script.

The core of the exploit lies in the nested while(1) loops that perform string concatenation.

• Outer Script (a initialization and main loop):

  • The variable a is initialized with a string that itself contains a JavaScript snippet.
  • The main while(1) loop then takes this initial string a and repeatedly doubles it (a=a+a).
  • Each doubled string is then written to the document using document.write(a).

• Inner Script (contained within a):

  • This script defines a variable b and assigns it an <iframe> tag.
  • The <iframe>'s src attribute is set to javascript:window.location="boom". This is a way to execute JavaScript within the context of the iframe.
  • The inner while(1) loop then attempts to duplicate b and write it.

Execution Flow:

1. The browser encounters the <script> tag.
2. The JavaScript engine starts executing the code.
3. Variable a is initialized with the string containing the inner script.
4. The main while(1) loop begins.
5. In the first iteration, a is concatenated with itself (doubled). The resulting, larger string is written to the document.
6. In the second iteration, the now-larger a is doubled again, becoming four times its original size. This even larger string is written.
7. This process continues indefinitely. The string a grows exponentially (1, 2, 4, 8, 16, ... times its original size).
8. As document.write(a) is called with increasingly large strings, the browser's memory allocation for the document's DOM and JavaScript heap grows rapidly.
9. Eventually, the browser exhausts available memory, leading to a crash or freeze.

No distinct shellcode/payload bytes are present; the exploit is purely JavaScript string manipulation.

Practical details for offensive operations teams

This exploit is a classic example of a client-side Denial of Service (DoS) vulnerability.

• Required Access Level: No elevated privileges are required. The attacker only needs to deliver a malicious HTML file or a link to a web page containing this JavaScript to the target user.
• Lab Preconditions:
  • A target machine with Apple Safari 4.0.3 or 4.0.4 installed on Windows.
  • A web server to host the malicious HTML file, or the ability to deliver the HTML file directly to the target (e.g., via email attachment, USB drive).
  • A controlled network environment for testing.
• Tooling Assumptions:
  • A simple text editor to create the HTML file.
  • A web server (e.g., Python's SimpleHTTPServer, Apache, Nginx) if hosting remotely.
  • A way to deliver the HTML file to the target.
• Execution Pitfalls:
  • Browser Version Specificity: This exploit is highly dependent on the specific Safari versions mentioned. Newer versions or other browsers will likely not be affected.
  • User Interaction: The target user must open the HTML file or visit the malicious URL in the vulnerable Safari browser.
  • Detection: While the exploit itself is simple JavaScript, the delivery mechanism (e.g., email, phishing page) might be subject to detection by security controls.
  • Limited Impact: This is a DoS. It does not lead to code execution, data exfiltration, or persistence. The primary goal is to disrupt the user's ability to use the browser.
  • Resource Consumption: The exploit consumes significant CPU and memory on the client machine. If the target machine has very limited resources, it might crash quickly. If it has abundant resources, it might take longer, or the browser might recover if the user can force-close it.
  • No Evasion: The JavaScript is plain and easily readable. There are no obfuscation techniques beyond the minor </scr"+"ipt> split, which is trivial to bypass.

Where this was used and when

• Context: This vulnerability was discovered and published in 2010. It would have been relevant in environments where Safari 4.0.3/4.0.4 was a commonly used browser on Windows machines. This could include corporate environments, educational institutions, or individual users.
• Usage: Exploits like this are typically used for:
  • Disruption: To temporarily disable a user's browser, preventing them from accessing specific resources or performing tasks.
  • Proof of Concept: To demonstrate the existence of a vulnerability to vendors or security researchers.
  • Low-level attacks: In scenarios where a more sophisticated exploit is not feasible or necessary, a simple DoS can be a stepping stone or a nuisance tactic.
• Approximate Years/Dates: Published in April 2010. The vulnerability would have been actively exploitable around this time and for a period afterward until users updated their browsers.

Defensive lessons for modern teams

While this specific vulnerability is very old and Safari 4 is long obsolete, the underlying principles of resource exhaustion attacks remain relevant.

• Keep Software Updated: The most effective defense is to ensure all software, especially browsers and plugins, are kept up-to-date with the latest security patches. This vulnerability was fixed in later versions of Safari.
• Browser Sandboxing: Modern browsers employ robust sandboxing mechanisms. These isolate web content and scripts from the operating system and other browser processes, significantly limiting the impact of client-side DoS attacks. A DoS in a sandboxed environment would typically only affect the browser tab or process, not the entire system.
• Resource Limits: Operating systems and browsers have internal mechanisms to limit the resources (memory, CPU) a single process or tab can consume. While an attacker might still cause a crash, these limits prevent the entire system from becoming unresponsive.
• JavaScript Engine Security: Modern JavaScript engines are highly optimized and include safeguards against runaway script execution and excessive memory allocation.
• Web Application Firewalls (WAFs): While this exploit targets the browser, a WAF could potentially detect and block malicious JavaScript if it were being served from a compromised web server. However, this specific DoS script is unlikely to trigger generic WAF rules unless specifically tailored.
• User Education: Educating users about the risks of opening untrusted files or visiting suspicious websites is a fundamental defense.

ASCII visual (if applicable)

This exploit is a client-side script execution. An ASCII visual can illustrate the process of string growth and memory consumption.

+-------------------+
| Target Browser    |
| (Safari 4.0.x)    |
+-------------------+
        |
        | Loads HTML with malicious JS
        v
+-------------------+
| JavaScript Engine |
|                   |
| 1. Init 'a'       |
|    a = "..."      |
|                   |
| 2. Loop 1:        |
|    a = a + a      |  <-- String doubles
|    document.write(a)|  <-- Writes large string
|                   |
| 3. Loop 2:        |
|    a = a + a      |  <-- String doubles again
|    document.write(a)|  <-- Writes even larger string
|                   |
| ...               |
|                   |
| Infinite Growth   |
|                   |
+-------------------+
        |
        | Memory Exhaustion
        v
+-------------------+
| Browser Crash/    |
| Freeze            |
+-------------------+

Source references

• PAPER ID: 12437
• PAPER TITLE: Apple Safari 4.0.3/4.0.4 - Stack Exhaustion
• AUTHOR: Fredrik Nordberg Almroth
• PUBLISHED: 2010-04-28
• KEYWORDS: Windows,dos
• PAPER URL: https://www.exploit-db.com/papers/12437
• RAW URL: https://www.exploit-db.com/raw/12437

Original Exploit-DB Content (Verbatim)

<script>
//Written by: Fredrik Nordberg Almroth
//URL: http://h.ackack.net/
//Affected: Safari 4.0.3 & 4.0.4 - Other versions might be vulnerable aswell.
  a="<script>var b=\"<iframe src='javascript:window.location=\"boom\"'></iframe>\";while(1){b=b+b;document.write(b);}</scr"+"ipt>";
  while(1){
    a=a+a;
    document.write(a);
  }
</script>