full-disclosure - OSX Safari "PAC" url DoS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date: Wed Jun 22 22:42:10 2005
From: kkadow at gmail.com (Kevin)
Subject: OSX Safari "PAC" url DoS

On 6/21/05, mac@....net <mac@....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