[VulnWatch] More OmniHTTPd ProblemsFrom: Matthew Murphy (firstname.lastname@example.org)
- Previous message: Matthew Murphy: "[VulnWatch] OmniHTTPd test.shtml Cross-Site Scripting Issue"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "Matthew Murphy" <email@example.com> To: "BugTraq" <firstname.lastname@example.org>, "Full Disclosure" <email@example.com>, "SecurITeam News" <firstname.lastname@example.org>, "Vuln-Dev" <email@example.com>, "VulnWatch" <firstname.lastname@example.org>, "VulnDiscuss" <email@example.com> Date: Sun, 25 Aug 2002 11:50:11 -0500
I've discovered another vulnerability in one of the OmniHTTPd sample apps.
This time, the culprit is "/cgi-bin/redir.exe". This app is vulnerable to a
newline injection issue. The vulnerability occurs because the "URL" query
parameter (case sensitive) is decoded and placed directly into the response
as the "Location" header. If an attacker places urlencoded newlines
("%0D%0A") into the parameter, the headers following the "Location" header,
as well as the resultant entity, can be controlled.
I had a tough time exploiting this vulnerability to add headers, because
OmniHTTPd would not add my header. :-( However, I was able to exploit this
vulnerability to produce the following output:
[Begin Server Response]
HTTP/1.0 302 Redirection
Date: Sun, 25 Aug 2002 16:36:39 GMT
[End Server Response]
This will pop up an alert, and then redirect to yahoo.com on browsers that
display redirect entities (IE will not work for this)
I was a bit puzzled by the "Server" header between the Location and the
entity, but I figured out that OmniHTTPd was inserting the header after CGI
processing was complete.
"The reason the mainstream is thought
of as a stream is because it is
- Author Unknown