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] [day] [month] [year] [list]
Date: Mon, 26 Jun 2006 15:31:58 -0400
From: "James C. Slora Jr." <james.slora@...a.com>
To: <bugtraq@...urityfocus.com>
Subject: RE: Bypassing of web filters by using ASCII


Hubert Seiwert wrote Monday, June 26, 2006 1:57 PM

> I don't currently see how this "ascii vulnerability" would make code 
> injection possible on webservers where the Content-Type is not 
> US-ASCII already, as the 3 methods mentioned to change the charset 
> (http-equiv content-type header, CSS @charset, document.charset) 
> depend on being able to inject things already.

Agreed - the ASCII vulnerability doesn't make servers less secure. It
doesn't make user-agents less secure either, since nothing here has
exposed any new attack vectors. It merely introduces a big, glaring,
open way for hostile code to evade detection when delivered from hostile
servers or in served code that is already vulnerable to injection. Doing
this without XSS can further exploit site trust.

So while the merits of IE's US-ASCII rendering choice can be easily
debated, products that claim to help protect IE users by detecting
hostile code need to step up and cover the ASCII issue fully.

- Jim








Powered by blists - more mailing lists