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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <459BF2B6.4050807@gmail.com>
Date: Wed, 03 Jan 2007 20:15:18 +0200
From: Amit Klein <aksecurity@...il.com>
To: bugtraq@...urityfocus.com,
	Web Security <websecurity@...appsec.org>
Subject: Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous

Amit Klein wrote:
> pdp (architect) wrote:
>> I will be very quick and just point to links where you can read about
>> this issue.
>>
>> It seams that PDF documents can execute JavaScript code for no
>> apparent reason by using the following template:
>>
>>    
>> http://path/to/pdf/file.pdf#whatever_name_you_want=javascript:your_code_here 
>>
>>
>> You must understand that the attacker doesn't need to have write
>> access to the specified PDF document. In order to get an XSS vector
>> working you need to have a PDF file hosted on the target and that's
>> all about it. The rest is just a matter of your abilities and desires.
>>
> Amazing, and kudos to Sven Vetsch who found this.
>
Oops, seems that the credit went to the wrong guy. Actual credit go to 
Stefano Di Paola, with contributions from Giorgio Fedon (IE Dos, UXSS 
Analysis) and Elia Florio (Poc and Code Execution analysis).

BTW, one way to mitigate this is for the server, upon receiving a 
request to file.pdf (without a valid query+cookie pair, see below), to 
redirect it to file.pdf?token_query=X (where X is an unpredictable, high 
entropy string) accompanied with a Set-Cookie header for a cookie named 
say "token_cookie" with value X and short expiration period (e.g. 10 
seconds). The browser will then respond with a request to 
file.pdf?token_query=X with Cookie token_cookie=X. At this point, if the 
server receives token_query==token_cookie, the server knows this is a 
legit request (i.e. without fragment), and it can safely serve the PDF 
resource.

I suppose this can be implemented easily as an Apache module/ISAPI/NSAPI 
filters.

-Amit

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ