'Day One' for Safari for Windows Becomes Zero-Day Nightmare

It took security engineers perhaps less than two hours yesterday to introduce Apple's surprise entry in the field of Windows browsers to the big, cruel world of exploits and vulnerabilities, following its introduction yesterday morning at WWDC. As a result, much of the clout Safari had received as the secure browsing alternative to Internet Explorer and Firefox -- as long as it was on a Macintosh -- was burned off like fire to a flash fuse.

Errata Security engineer David Maynor had a report posted on the first vulnerability he found by 1:48 pm, complete with screenshots of the pre-crash letdown dialog produced by his fuzzing tool. As he admitted, it wasn't a difficult crash to find, posting a screen shot of the memory dump revealing both a stack corruption and an access violation, and then giving credit to Thor Larholm for posting a complete report on the calamity not an hour later.

"I downloaded and installed Safari for Windows 2 hours ago, when I started writing this," Larholm wrote, "and I now have a fully functional command execution vulnerability, triggered without user interaction simply by visiting a web site."

Both Larholm and Maynor have made it clear their intentions are simply to discover vulnerabilities and warn the vendor and the public as to their implications, not to profit from their exploitation...because, quite frankly, the exploits don't appear to be that difficult.

Apple's Web site touts, "Apple engineers designed Safari to be secure from day one." As Larholm explained on his blog, that may very well be correct: Its engineers obviously designed Safari to take advantage of security protocols in the OS X operating system, as evidenced by function calls to those protocols Larholm located inside the source code for the Windows version - calls which would obviously go unfulfilled.

"On the OS X platform," he continued, "Apple has enjoyed the same luxury and the same curse as Internet Explorer has had on the Windows platform, namely intimate operating system knowledge." As a result, Safari for Windows may be expecting other layers of the operating system to provide security - layers which aren't present on Windows, especially since Microsoft has naturally adapted its transport layer security for optimum use with IE7.

As an example -- one which may be as important for Firefox as for Safari -- Larholm demonstrated the use of an inline frame <IFRAME> element with embedded JavaScript code. When delivered to Safari, it passes on an unfiltered request to the old Gopher protocol, which on his system is handled by Firefox. That browser then processes the unfiltered request raw, with the result being that CMD.EXE is called, pulling up the command line.

If Larholm wished to go further with this demonstration, he could have passed a default command to CMD.EXE - which, of course, would also have been unfiltered.

Safari is built on top of an open-source Web browser engine called WebKit, whose developers announced on their blog this morning that the first nightly build of the Windows version of WebKit will be released sometime today. At that time, perhaps veteran Windows developers may become available to flesh out and plug the holes which Safari's disconnection from Mac OS X left open.