From gtheall at tenable.com  Wed Dec  4 20:48:01 2013
From: gtheall at tenable.com (George Theall)
Date: Thu, 5 Dec 2013 02:48:01 +0000
Subject: [VIM] Pete Stein GoScript Remote Command Execution Vulnerability
Message-ID: <B871970B-1F11-4486-86E9-1940C031351E@tenable.com>

I notice that SecurityFocus updated BID 10853 yesterday to include Monitorix among the affected products, presumably based on <https://github.com/mikaku/Monitorix/issues/30>. That?s incorrect. While our plugin that checks for the GoScript go.cgi code execution vulnerability does indeed flag Monitorix installs before 3.3.1, that application actually does not include the GoScript go.cgi and in fact the vulnerability arises because of the following code in the HTTP server itself :

        $target =~ s/^\///;                # removes leading slash
        $target_cgi =~ s/^\///;                # removes leading slash
        if($target_cgi eq "monitorix.cgi") {
                chdir("cgi");
                open(EXEC, "./$target_cgi |");
                @data = <EXEC>;
                close(EXEC);
        } elsif($target) {
                if(open(IN, $target)) {
                        @data = <IN>;
                        close(IN);
                }
        }

That is, it fails to sanitize the target_cgi value before using it in a Perl ?open()? call; even <http://example.com/some_nonexistent_url|id|> would work against it.


George
-- 
theall at tenable.com


From Dinesh_Theerthagiri at symantec.com  Tue Dec 10 04:00:51 2013
From: Dinesh_Theerthagiri at symantec.com (Dinesh Theerthagiri)
Date: Tue, 10 Dec 2013 02:00:51 -0800
Subject: [VIM] Pete Stein GoScript Remote Command Execution Vulnerability
In-Reply-To: <B871970B-1F11-4486-86E9-1940C031351E@tenable.com>
References: <B871970B-1F11-4486-86E9-1940C031351E@tenable.com>
Message-ID: <86E9E90EE35E9041B100B9ED1D5C8B5745A664C24E@APJ1XCHEVSPIN30.SYMC.SYMANTEC.COM>

George,

We Updated BID: 10853 accordingly.

Monitorix technologies removed from this BID because information does not relate to this document.

Wrote different BID for Monitorix  64178.


Thanks,
T.Dinesh



-----Original Message-----
From: vim-bounces at attrition.org [mailto:vim-bounces at attrition.org] On Behalf Of George Theall
Sent: Thursday, December 05, 2013 8:18 AM
To: Vulnerability Information Managers
Subject: [VIM] Pete Stein GoScript Remote Command Execution Vulnerability

I notice that SecurityFocus updated BID 10853 yesterday to include Monitorix among the affected products, presumably based on <https://github.com/mikaku/Monitorix/issues/30>. That's incorrect. While our plugin that checks for the GoScript go.cgi code execution vulnerability does indeed flag Monitorix installs before 3.3.1, that application actually does not include the GoScript go.cgi and in fact the vulnerability arises because of the following code in the HTTP server itself :

        $target =~ s/^\///;                # removes leading slash
        $target_cgi =~ s/^\///;                # removes leading slash
        if($target_cgi eq "monitorix.cgi") {
                chdir("cgi");
                open(EXEC, "./$target_cgi |");
                @data = <EXEC>;
                close(EXEC);
        } elsif($target) {
                if(open(IN, $target)) {
                        @data = <IN>;
                        close(IN);
                }
        }

That is, it fails to sanitize the target_cgi value before using it in a Perl 'open()' call; even <http://example.com/some_nonexistent_url|id|> would work against it.


George
-- 
theall at tenable.com


From gtheall at tenable.com  Tue Dec 10 06:00:03 2013
From: gtheall at tenable.com (George Theall)
Date: Tue, 10 Dec 2013 12:00:03 +0000
Subject: [VIM] Pete Stein GoScript Remote Command Execution Vulnerability
In-Reply-To: <86E9E90EE35E9041B100B9ED1D5C8B5745A664C24E@APJ1XCHEVSPIN30.SYMC.SYMANTEC.COM>
References: <B871970B-1F11-4486-86E9-1940C031351E@tenable.com>
	<86E9E90EE35E9041B100B9ED1D5C8B5745A664C24E@APJ1XCHEVSPIN30.SYMC.SYMANTEC.COM>
Message-ID: <AA791F81-59CB-4342-9EEF-765E17A9FCB1@tenable.com>


On Dec 10, 2013, at 5:00 AM, Dinesh Theerthagiri <Dinesh_Theerthagiri at symantec.com> wrote:

> George,
> 
> We Updated BID: 10853 accordingly.
> 
> Monitorix technologies removed from this BID because information does not relate to this document.
> 
> Wrote different BID for Monitorix  64178.

Dinesh, the description in the new BID talks about the go.cgi script - "Specifically, this issue affects the 'go.cgi' script.?.  The Monitorix code doesn?t actually have that script ? see my earlier response about why the vulnerability arises.

> 
> 
> Thanks,
> T.Dinesh
> 
> 
> 
> -----Original Message-----
> From: vim-bounces at attrition.org [mailto:vim-bounces at attrition.org] On Behalf Of George Theall
> Sent: Thursday, December 05, 2013 8:18 AM
> To: Vulnerability Information Managers
> Subject: [VIM] Pete Stein GoScript Remote Command Execution Vulnerability
> 
> I notice that SecurityFocus updated BID 10853 yesterday to include Monitorix among the affected products, presumably based on <https://github.com/mikaku/Monitorix/issues/30>. That's incorrect. While our plugin that checks for the GoScript go.cgi code execution vulnerability does indeed flag Monitorix installs before 3.3.1, that application actually does not include the GoScript go.cgi and in fact the vulnerability arises because of the following code in the HTTP server itself :
> 
>        $target =~ s/^\///;                # removes leading slash
>        $target_cgi =~ s/^\///;                # removes leading slash
>        if($target_cgi eq "monitorix.cgi") {
>                chdir("cgi");
>                open(EXEC, "./$target_cgi |");
>                @data = <EXEC>;
>                close(EXEC);
>        } elsif($target) {
>                if(open(IN, $target)) {
>                        @data = <IN>;
>                        close(IN);
>                }
>        }
> 
> That is, it fails to sanitize the target_cgi value before using it in a Perl 'open()' call; even <http://example.com/some_nonexistent_url|id|> would work against it.
> 
> 
> George
> -- 
> theall at tenable.com
> 

George
-- 
theall at tenable.com


From coley at mitre.org  Wed Dec 18 19:24:38 2013
From: coley at mitre.org (Christey, Steven M.)
Date: Thu, 19 Dec 2013 01:24:38 +0000
Subject: [VIM] OG Features module bypass / CVE-2013-7067 version
	inconsistencies
Message-ID: <FC72FC641B949240B947AC6F1F83FBAF33E619FD@IMCMBX01.MITRE.ORG>

Refs: CONFIRM:https://drupal.org/node/2149743
MISC:https://drupal.org/node/2149791

X-Force, SecurityFocus, and OSVDB all state that  6.x-1.2 is the last version affected.  This is likely due to a segment in 2149791 that "versions prior to 6.x-1.3" are affected.  However, in the same advisory a couple lines later, the Drupal team says "upgrade to OG Features 6.x-1.4," linking to 2149743 - the maintainer's advisory, which identifies 6.x-1.4 and clearly mentions the vulnerability.

Since 6.x-1.3 was released on February 14, 2012 according to https://drupal.org/node/1080238, it is our opinion that 6.x-1.3 is also vulnerable.

- Steve


From coley at mitre.org  Mon Dec 30 17:23:52 2013
From: coley at mitre.org (Christey, Steven M.)
Date: Mon, 30 Dec 2013 23:23:52 +0000
Subject: [VIM] Recent Neohapsis URLs are empty
Message-ID: <FC72FC641B949240B947AC6F1F83FBAF33E7EC9C@IMCMBX01.MITRE.ORG>

Has anybody else noticed that recent Neohapsis URLs are basically empty?  For example, http://archives.neohapsis.com/archives/bugtraq/2013-12/index.html lists recent Bugtraq posts but http://archives.neohapsis.com/archives/bugtraq/2013-12/0134.html has no contents, and http://archives.neohapsis.com/archives/bugtraq/2013-12/0107.html only contains a "0".

Looks like a lot of other lists on this site have the same problem.

It's unfortunate, since this site has been pretty reliable for 10+ years, and not a lot of archive sites are like that.

I have an inquiry into the webmaster.  Crossing my fingers...

- Steve


From jericho at attrition.org  Mon Dec 30 17:41:29 2013
From: jericho at attrition.org (security curmudgeon)
Date: Mon, 30 Dec 2013 17:41:29 -0600 (CST)
Subject: [VIM] Recent Neohapsis URLs are empty
In-Reply-To: <FC72FC641B949240B947AC6F1F83FBAF33E7EC9C@IMCMBX01.MITRE.ORG>
References: <FC72FC641B949240B947AC6F1F83FBAF33E7EC9C@IMCMBX01.MITRE.ORG>
Message-ID: <alpine.LNX.2.00.1312301741150.13149@forced.attrition.org>


I forwarded this to their webmaster, who is typically very responsive in 
the past.

On Mon, 30 Dec 2013, Christey, Steven M. wrote:

: Has anybody else noticed that recent Neohapsis URLs are basically empty?  For example, http://archives.neohapsis.com/archives/bugtraq/2013-12/index.html lists recent Bugtraq posts but http://archives.neohapsis.com/archives/bugtraq/2013-12/0134.html has no contents, and http://archives.neohapsis.com/archives/bugtraq/2013-12/0107.html only contains a "0".
: 
: Looks like a lot of other lists on this site have the same problem.
: 
: It's unfortunate, since this site has been pretty reliable for 10+ years, and not a lot of archive sites are like that.
: 
: I have an inquiry into the webmaster.  Crossing my fingers...
: 
: - Steve
: 

From coley at mitre.org  Mon Dec 30 17:51:09 2013
From: coley at mitre.org (Christey, Steven M.)
Date: Mon, 30 Dec 2013 23:51:09 +0000
Subject: [VIM] Recent Neohapsis URLs are empty
In-Reply-To: <alpine.LNX.2.00.1312301741150.13149@forced.attrition.org>
References: <FC72FC641B949240B947AC6F1F83FBAF33E7EC9C@IMCMBX01.MITRE.ORG>
	<alpine.LNX.2.00.1312301741150.13149@forced.attrition.org>
Message-ID: <FC72FC641B949240B947AC6F1F83FBAF33E7FCFC@IMCMBX01.MITRE.ORG>

Indeed, my initial inquiry was answered within a matter of minutes!  Hopefully it will be resolved soon.

Over the years, CVE has had to alternate between multiple archives due to temporary or permanent outages.  It comes with the territory, I guess :)

- Steve


>-----Original Message-----
>From: vim-bounces at attrition.org [mailto:vim-bounces at attrition.org] On
>Behalf Of security curmudgeon
>Sent: Monday, December 30, 2013 6:41 PM
>To: Vulnerability Information Managers
>Subject: Re: [VIM] Recent Neohapsis URLs are empty
>Importance: High
>
>
>I forwarded this to their webmaster, who is typically very responsive in
>the past.
>
>On Mon, 30 Dec 2013, Christey, Steven M. wrote:
>
>: Has anybody else noticed that recent Neohapsis URLs are basically empty?