About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Home » Learning Curve » Hotspots

Revisiting the Safari Vulnerability on Windows

Are things any better on OS X?

Get It

Try It

Things aren't secure on Microsoft Windows and they never will be. But is it then OK for others to supply software for that platform that ends up getting clobbered as well?

As software slowly becomes platform agnostic and as malware engineers inevitably hone their skills this becomes an increasingly important issue.

Nitesh Dhanjani wrote about his 'Safari carpet bomb' in May. By then he'd already contacted Apple. Dhanjani regarded the discovery as three separate security issues. He got a lukewarm response from Apple (but an advisory from Microsoft).

  1. Safari carpet bomb. It is possible for a rogue website to litter the user's desktop (Windows) or downloads directory (on OS X). This can happen because the Safari browser cannot be configured to obtain the user's permission before it downloads a resource. Safari downloads the resource without the user's consent and places it in a default location (unless changed).
  2. Sandbox not applied to local resources. Internet Explorer warns users when a local resource such as an HTML file attempts to invoke client side scripting. Not Safari.
  3. Undisclosed. A high risk vulnerability in Safari that can be used to remotely steal local files from the user's file system.

Apple were interested in the third issue but not particularly interested in the first. And now that first issue is possibly coming back to haunt again. And not as Apple described it - as an 'enhancement request'.


Windows has a funky way of resolving 'external references'. External references have to do with the fact that all graphics intensive systems (normally with GUIs) can't possibly bake all their code in the same executable. Whether it be called a dynamic link library, a shared library, or a framework: the end result is the same. There's code out there you need and it's not in your program file on disk - but it must be in your process address space once you load.

Apple solve this in a strict and safe manner. All apps must specify exactly where their 'dependencies' are going to reside at runtime. Apple's OS does not permit changing these locations - Windows does.

[OS X users can run 'otool -L' on any of their binaries to see this in more detail. Ed.]

Windows has a strict system for evaluating where to look for these dependencies but their paths are not stipulated at build time - the system hunts them down at runtime instead. And the 'current working directory' can be the first place the system searches for them. And on boot and login the 'desktop' can be the current working directory.

The bread's burning.

Nice Calculators

Aviv Raff's uploaded a POC to milw0rm. Given this DLL is found in the right location and given one of the three suggested names is used it will be loaded. And when it does it can almost literally do anything. And it will be loaded as long as Windows finds it before it finds the real one.

Scroll to the code line in red to see how AV gets his command line ready to run a bunch of nice calculators.

        Copyright (C) 2006-2007 Aviv Raff
        Greetz: hdm, L.M.H, str0ke, SkyLined

        Compile and upload to the victim's desktop as one of the following hidden DLL files:
        - sqmapi.dll
        - imageres.dll
        - schannel.dll

        Run IE7 and watch the nice calculators pop up.
        Filter fdwReason to execute only once.

        Tested on WinXP SP2 with fully patched IE7.
        For testing/educational purpose only!


#include <windows.h>

  DWORD fdwReason,
  LPVOID lpvReserved
    TCHAR windir[_MAX_PATH];
    TCHAR cmd[ _MAX_PATH ];
    GetEnvironmentVariable("WINDIR",windir,_MAX_PATH );
    si.cb = sizeof(si);
    return TRUE;

// milw0rm.com [2006-12-14]

[Note this is still a 'Windows only' vulnerability. Ed.]

Aviv hasn't been happy with Microsoft - repeatedly hammering on them for letting this hole remain open. 'It's still heaven for spyware writers', he wrote back in November 2006.

The new version of Internet Explorer is vulnerable to a DLL-load hijacking. When IE7 is executed it will load several DLL files. While trying to load some of those files, it does not provide the full path of the DLL file to the function which loads the DLL file to the memory, and therefore Windows will search for this file in the user's machine using the directories provided in the PATH environment variable and will load the first match it will found [sic].

Now, all the attacker has to do to bypass this detection is to put a malicious DLL file (or just a downloader DLL of a malicious file) in one of the PATH directories (eg the user's desktop), and the next time the user will run IE7 the code of the attacker's file will be executed instead of the original DLL.

Gorgeous. About what you'd expect of Microsoft. But it doesn't end there. It gets worse.

Moreover, the attacker can hide the DLL by setting an hidden file attribute. As most users have the option of not showing hidden files enabled (this is the default settings) it will not show them the malicious file on the user's desktop, but still IE7 will load the file.

Oh whoopee. But no worries - it still gets worse. Aviv reported this (rather well known) condition to Microsoft and got the following response.

'If the attacker can put a DLL on the box in a location that is in the user's PATH variable then they already own the box'.

Which of course is USDA prime time rubbish.

Safe DLL Search Order

Microsoft do have a type of safeguard against the above. It's a band-aid called 'Safe DLL Search Order'. It's controlled by the following Registry key. This key is on by default beyond XP and can be reset on all Windows systems - provided a process can get on the system and run. Windows has other ways to secure the DLL search order but it's not known if they're secure.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode

And what most often happens with these Registry band-aids is the black hats simply go into the Registry and turn everything around again.

Safari Pwns Internet Explorer

And now Apple come into the picture. For Apple's web browser Safari now runs on Windows.

[Not the entire Apple OS as was promised ten years ago - just the web browser. Sorry. Ed.]

Aviv Raff reported the issue to Microsoft in May 2008. Microsoft issued an advisory by the end of the same month.

Microsoft Security Advisory (953818)

Blended Threat from Combined Attack Using Apple's Safari on the Windows Platform

Microsoft is investigating new public reports of a blended threat that allows remote code execution on all supported versions of Windows XP and Windows Vista when Apple's Safari for Windows has been installed. Safari is not installed with Windows XP or Windows Vista by default; it must be installed independently or through the Apple Software Update application. Customers running Safari on Windows should review this advisory.

At the present time, Microsoft is unaware of any attacks attempting to exploit this blended threat. Upon completion of this investigation, Microsoft will take the appropriate measures to protect our customers. This may include providing a solution through a service pack, the monthly update process, or an out-of-cycle security update, depending on customers needs.

Mitigating Factors:

  • Customers who have changed the default location where Safari downloads content to the local drive are not affected by this blended threat.

    Now Liu Die Yu gets in the picture and Brian Krebs picks the story up again.

    The old vulnerability Aviv Raff reported to Microsoft long time ago is described in two articles by Aviv Raff dating back to 2006 (yeah that's really 'a long long time ago'). This vulnerability lies in Windows Internet Explorer loading program library files (DLLs) from a user's desktop instead of its own library file folder (usually C:\WINDOWS\SYSTEM32) when filenames are set to some specific values.

    Safari for Windows downloads files to the desktop by default with no confirmation - which is a quite reasonable and convenient feature. And Windows Internet Explorer loads program libraries (DLLs) from the desktop if the filename is set to some specific value. Two things added up, or 'blended'. IE loads library files downloaded by Safari. The action of loading a library runs code in the library file and loading the wrong file results in executing the wrong code.

    Here's Liu's POC code. It's of course very similar to AV's.

    #include <windows.h>
        HINSTANCE hinstDLL,
        DWORD fdwReason,
        LPVOID lpvReserved
        STARTUPINFO si;
        si.cb = sizeof(si);
        CreateProcess(NULL,"NOTEPAD \"=====(((((we are in)))))=====\"",NULL,NULL,FALSE,0,NULL,NULL,&si,&pi);
        return TRUE;

    Then you just rename the resulting executable to something cute as AV suggested and put it up on your nasty website in a page like this. Notice how easy it is: simply put the payload in an IFRAME.

    <title>Safari for Windows Proof of Concept (Incident in June 2008)</title>
    Safari for Windows Proof of Concept (Incident in June 2008)<br>
    <a href="http://liudieyu0.blog124.fc2.com/blog-entry-1.html">Detailed Analysis Available on My Blog ...</a><br>
    Step 1. Browse this web page with Safari for Windows, and download is copied to Desktop.
    It's a legitimate feature.<br>
    <iframe src="schannel.dll" width=1 height=1></iframe><br>
    Step 2. Now launch Internet Explorer from Desktop or Start Menu, and code from the DLL file is executed.
    <i>This is the issue.</i><br>
    Code in the DLL file launches NOTEPAD to open a file that doesn't exist.<br>
    Please remove the downloaded DLL file on Desktop after testing.<br>

    Final Words

    The final words - from Liu at any rate.

    A design flaw in Windows Internet Explorer both version 8 beta, 7, and probably others, breaks the security of Safari for Windows shipped by Apple. The problem originated from an error that Windows Internet Explorer will load program library files (DLLs) from the user's desktop instead of its own library file folder (usually C:\WINDOWS\SYSTEM32). Apple's Safari for Windows downloads and saves files to the user's desktop by default. This default behaviour itself does not constitute a mistake. Microsoft used vague wording in the advisory: 'suggested actions' are 'restrict use of Safari as a web browser' - as if it's a flaw rooted in Safari.

    In a subfolder of 'suggested actions' Microsoft admit to 'workarounds' such as 'change the download location of content in Safari to a newly created directory'. The full statement should be 'change the download location of content in Safari to a newly created directory (to save the integrity of Windows Internet Explorer)'.

    I'm not an Apple fan. In fact I applied for their position of Safari for Windows Tester and they never replied. It's not so lame because they don't even get back to reporters when the whole world is accusing their product - 'an Apple spokesman did not return a phone call and e-mail seeking comment'.

    I believe in time all things come to light.

    But that's still not the end of it. For now shall the chickens come home to roost.

    It's an App!

    Of course the situation's far worse on Windows where anything can happen and everything usually happens. But what happens back in the world of Apple?

    On Apple's OS X 10.4 Tiger things are a bit more involved. On both 10.4 and 10.5 Leopard Safari will arbitrarily append a second file extension ('EXE'). And on Tiger you'll get an explicit alert.

    After that you simply cancel the download.

    But things are a bit different on Leopard 10.5. Leopard relies on a 'quarantine' extended attribute to save you. With Safari on Leopard you don't get told there's been a download at all. Only if your 'downloads' window is visible will you see it.

    It's only when you directly access the file you'll get an alert. And again: this is because the file has a 'quarantine' extended attribute.

    But if some other process used this file indirectly it's unlikely you'd get that alert.

    Apple's OS X has the immense advantage over Windows that paths to dependencies are set at build time and not at runtime. There was a bug, intentional or not, in versions prior to Tiger that ignored the 'tilde' in paths but that's since been corrected.

    Still and all: Safari for Leopard will download files without asking the user's permission. It's possible to do this without being detected. At which point the payload is inside the perimeter. Can it be exploited from there?

    No exploit has been found yet. OS X is a lot more secure than Windows. But it took almost two years for AV's original POC to get this far. Anything can happen.

    The most important thing is ensuring Safari users on all platforms without exception get asked for their express permission before the program downloads anything at all.

    See Also
    Microsoft: Security Advisory 953818
    Nitesh Dhanjani: Safari Carpet Bomb
    Aviv Raff: Safari Pwns Internet Explorer
    Security Fix: Safari Flaw a Danger to Windows Users
    Security Fix: Revisiting the Safari Vulnerability on Windows
    Aviv Raff: Internet Explorer 7 - Still Spyware Writers Heaven
    Aviv Raff: IE7 DLL-load hijacking Code Execution Exploit POC
    LIUDIEYU[0]: Remote Code Execution from Safari for Windows
    milw0rm: MS Internet Explorer 7 DLL Load Hijacking Exploit POC

    About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
    Copyright © Rixstep. All rights reserved.