bugtraq - Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous

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]

Message-id: <459DF9C7.2040201@gmail.com>
Date: Fri, 05 Jan 2007 09:09:59 +0200
From: Amit Klein <aksecurity@...il.com>
To: James Landis <jcl24@...nell.edu>
Cc: RSnake <rsnake@...cking.com>, bugtraq@...urityfocus.com,
	Web Security <websecurity@...appsec.org>
Subject: Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous

James Landis wrote:
> More notes on Amit's remediation algorithm:
>
> Putting all of the identifying information into the token weakens the 
> defense because the attacker can mount known plaintext attacks against 
> it. 
Not precisely. First, the classic definition of "known plaintext 
attacks" is that an attacker can observe both the plaintext and the 
ciphertext, In our case, the attacker does see ciphertext, but he/she 
does not exactly see the plaintext. Obviously the IP is known, and the 
server time is known up to some granularity, but if (say) you use the 
microsecond clock, then an attacker will have a hard time guessing the 
*exact* plaintext.

I don't think known-plaintext attack should worry you if you use an 
industrial strength encryption, but if you feel like hardening the 
algorithm against this attack, you can always throw in a random number, 
or a secret string as part of the plaintext, and discard it upon decryption.
> Putting things in perspective, even if the attacker breaks the 
> encryption algorithm, they still have to know the IP address of the 
> target. However, a sufficiently clever attacker will simply create a 
> phishing scam which harvests IPs and creates custom URLs for each 
> victim. The algorithm will also be weakened against individually 
> targeted attacks because like you said, it does not protect users 
> which appear to come from the same IP to the Web server.
>
Even if the attacker knows the exact IP address of the victim, I don't 
see how this helps much. A good encryption algorithm will withstand a 
known plaintext attack. And since the attacker cannot fake TCP traffic 
coming from the victim's IP (unless the attacker and victim go out to 
the Internet from the same IP, or unless the attacker uses IP spoofing 
techniques not suitable for our kind of attacks), I don't see how the 
attacker can acquire a valid token for the attack.
> Amit's solution is a tradeoff with maintaining state for the "unique 
> tokens" described by RSnake. Unique tokes or nonces are a more secure 
> solution but using them incurs the additional overhead of tracking the 
> nonces. Amit's algorithm has no tracking overhead.
Why are they secure? Please consider the attack scheme I described in 
http://www.webappsec.org/lists/websecurity/archive/2007-01/msg00065.html

-Amit