Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security FullDisclosure
[Top] [All Lists]

Re: [Full-disclosure] OSX Safari "PAC" url DoS

Subject: Re: [Full-disclosure] OSX Safari "PAC" url DoS
Date: Wed, 22 Jun 2005 16:42:02 -0500
On 6/21/05, mac@msg.net <mac@msg.net> wrote:
Tiger's System Preferences set to fetch a PAC File URL from a web server
acts as a denial of service attack against the server where PAC is hosted.

I have an open support case with Apple on this issue.

It's not exactly exploitable, but I know of of multiple organizations who
have ended up revisiting every Tiger desktop and turn off PAC after the
cumulative effects of the bug start to appear.

Instead of just making one HTTP request for the PAC file when the
browser is first launched (as MSIE, Firefox, Opera, all do), Safari
generates a HTTP request to the PAC server once for each *object*
requested; for each HTTP request out to the Internet, a corresponding
request is made to a local HTTP server for the PAC file!

For example,  the CNN home page consists of 90 unique objects,
for each of which Safari makes a new TCP connection to the PAC
server, (specifying "Connection: close") and sends a HTTP/1.0 request,
then finally goes out to the Internet proxy and requests the actual object.

This isn't a big deal when you have ten workstations, but becomes a
major headache when you have ten thousand.  Eventually the server
hosting PAC will become overloaded, and now *nobody* can access
the Internet, not even the Mozilla or MS-Windows users.


When a local PAC file (a file::/localhost/... URL) is configured, the
network problems are avoided, but browser performance is poor,
with sporadic broken images and general slowness loading pages.

Apple technical support suggested that I could work around the above
problem by mounting a RAM disk and copying the PAC file from the
web server to the RAM disk after each reboot, possibly with a startup
script.  Creative, but not really something I can sell to management.

Proxy Client Auto-Config (aka "Proxy Automatic Configuration") is new
to Apple, but is not new tech.  Netscape's docs are dated March 1996:
    http://wp.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html

Normally a web browser retrieves a fresh copy of PAC when launched, and
then caches this copy, refreshing the contents only when the user forces
a reload of the script, based on the Expires header, or using an internal
refresh timer (Under MSIE, the PAC refresh time can be set using IEAK).

In MacOS Panther and Tiger, the option to configure proxy settings is
under System Preferences/Network/Proxies.  This menu gives the user
the option to set the "PAC File URL", but no option for how/whether the
script is cached/refreshed.  Also, Safari does not respect an Expires
header sent with the PAC file (to be fair, most browsers ignore this).


Workarounds:

Switching to Firefox eliminates this problem.  Firefox only downloads the
PAC file at session start, or when the user manually chooses to reload it.


Kevin Kadow
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

<Prev in Thread] Current Thread [Next in Thread>