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: <20070219163416.4376.qmail@securityfocus.com>
Date: 19 Feb 2007 16:34:16 -0000
From: hugo@...ohacking.com
To: bugtraq@...urityfocus.com
Subject: Re: Re: Apache Multiple Injection Vulnerabilities

Dear Sirs, 

I'll try to comment some of your statements about that issue.

"1. Zeus conforms that the "Error response arbitrary injection" method is not applicable to Zeus Web Server."
Right. I haven't tell this at any time.

"2. The "Location HTTP header injection" does affect Zeus Web Server, but only constitutes a vulnerability in a particular, uncommon use case for Zeus Web Server."
Ok, so we agree it's a vulnerability.

"Zeus agree that preserving any path information in the host header is not correct behavior. A more appropriate behaviour would be to return a 400 Bad Request response."
I really agree on this.

"This problem should not affect ordinary web clients because no such clients will generate this erroneous host header value."
I'm really atonished that nowadays some high skilled people still can think this... There are  many ways to "generate this erroneus host header" in client side, the first it comes to my mind is using advanced client side scripting -XMLhttp... calls, etc.-

"The author's assertion that a malicious attacker could use this behaviour to poison a web cache is incorrect in the vast majority of cases"
You have told it right: "Could be used". Many, many, many vulnerabilities, like memory corruption problems, end up in something like "could be used to run arbitrary code, etc." Could be used.... It depends on the specific scenario. Do we agree on this?

"A cache could be poisoned if it were deliberately configured to ignore the host header. "
Be careful with this statement... I think it would be more conservative to say: A cache could be poisoned if it is configured or if it's default behaviour or if in a specific scenario ignores the host header"

"This would only be the case if the cache was acting as an acceleration device, fronting a single domain on one web server."
The only case...Ummm, I'm not -by far- so clever nor so sure about this like you...

"If you are concerned about this behaviour, you can configure Zeus Web Server to remove path and port components from host headers in a request."
Why doing this? No reason for this... You are following RFC's, isnt'it? :-)

"Zeus respectfully requests that security issues are notified directly to Zeus before being publicly disclosed."
Yes, I know, and for that reason I contacted you on  "25-07-06 18:29". To be more specific I sent the email to: 
"support zeus com" and to "colinw zeus com".
Please review your SMTP logs.
Regarding that issue, maybe after not receiving a response I should have tryed to contact again... maybe for two or three times before made it public. Maybe I should have also contacted Microsoft, Google, or the half dozen vendors affected by this. Maybe I should stop working a whole week...
Or maybe, you, vendors, that spent millions of dollars and have a lot of human resources and power, could talk each other, have a beer and decide about a building a standarized reliable protocol for contacting you about this kind of issues...
Until that day, I will try to contact vendors depending on issues like: past feedback from that vendor, available time to spent on that issue, etc.

Having tell all this I could not end without expressing that I sincerely think Zeus Web Server is an impressive fast, reliable and secure web server, really nice and very user friendly.

As usually, a software project is by far mutch better than some people behind it.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ