[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bugtraq
Subject:    Re: [Fwd: Security Alert; possible buffer overflow in all Mathopd
From:       Peter Geissler <blasty () geekz ! nl>
Date:       2003-12-08 7:44:01
[Download RAW message or body]

In-Reply-To: <3FD09747.7010607@mpex.net>

Hi,

I took a look at the source of Mathopd (1.3pl8 to be exact), and I'm seeing the \
potiental security risk. but I can assure it isn't THAT high. Let's take a look at \
                some snippets of the source from prepare_replay():
--
	char *b, buf[2 * PATHLEN + 400];
	..
	if (send_message) {
		b = buf;
		b += sprintf(b, "<title>%s</title>\n"
			"<h1>%s</h1>\n", r->status_line, r->status_line);
		switch (r->status) {
		case 302:
			b += sprintf(b, "This document has moved to URL <a href=\"%s\">%s</a>.\n", \
r->location, r->location);  break;
		case 401:
			b += sprintf(b, "You need proper authorization to use this resource.\n");
			break;
		case 400:
		case 405:
		case 501:
		case 505:
			b += sprintf(b, "Your request was not understood or not allowed by this \
server.\n");  break;
		case 403:
			b += sprintf(b, "Access to this resource has been denied to you.\n");
			break;
		case 404:
			b += sprintf(b, "The resource requested could not be found on this server.\n");
			break;
		case 503:
			b += sprintf(b, "The server is temporarily busy.\n");
			break;
		default:
			b += sprintf(b, "An internal server error has occurred.\n");
			break;
		}
--
So, what happens is b becomes a pointer to buf. buf has a length of 2 * PATHLEN + \
400. Ok that's quite stupid, but that won't mean this will be exploitable. because \
buf is only affected by dynamic input when the response status is 302 (Document has \
moved) or when site admin needs to be contacted, no evil input is passed into buf \
(since it's not user defineable, these are admin settings). and a status line \
including error message never reaches 400+ chars (think of 2*PATHLEN + 400 ;-))

Just my 2 cents.

Regards,
Peter "blasty" Geissler

> Received: (qmail 20347 invoked from network); 5 Dec 2003 18:04:10 -0000
> Received: from outgoing3.securityfocus.com (205.206.231.27)
> by mail.securityfocus.com with SMTP; 5 Dec 2003 18:04:10 -0000
> Received: from lists2.securityfocus.com (lists2.securityfocus.com [205.206.231.20])
> 	by outgoing3.securityfocus.com (Postfix) with QMQP
> 	id 96610A312C; Fri,  5 Dec 2003 11:07:12 -0700 (MST)
> Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm
> Precedence: bulk
> List-Id: <bugtraq.list-id.securityfocus.com>
> List-Post: <mailto:bugtraq@securityfocus.com>
> List-Help: <mailto:bugtraq-help@securityfocus.com>
> List-Unsubscribe: <mailto:bugtraq-unsubscribe@securityfocus.com>
> List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com>
> Delivered-To: mailing list bugtraq@securityfocus.com
> Delivered-To: moderator for bugtraq@securityfocus.com
> Received: (qmail 5651 invoked from network); 5 Dec 2003 14:30:23 -0000
> Message-ID: <3FD09747.7010607@mpex.net>
> Date: Fri, 05 Dec 2003 15:33:43 +0100
> From: Gregor Lawatscheck <gpel@mpex.net>
> Organization: MPeX.net GmbH
> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 \
>                 Thunderbird/0.3
> X-Accept-Language: en-us, en
> MIME-Version: 1.0
> To: bugtraq@securityfocus.com
> Subject: [Fwd: Security Alert; possible buffer overflow in all Mathopd versions]
> Content-Type: text/plain; charset=us-ascii; format=flowed
> Content-Transfer-Encoding: 7bit
> 
> -------- Original Message --------
> Subject: Security Alert; possible buffer overflow in all Mathopd versions
> Date: Thu, 4 Dec 2003 22:33:26 +0100 (CET)
> From: Michiel Boland <michiel@boland.org>
> To: mathopd@mathopd.org
> 
> Hi.
> 
> During some testing, I came across a rather stupid and embarassing buffer
> overflow in request.c in all Mathopd versions up to and including 1.5b13.
> The problem is in the prepare_reply() function that allocates space for a
> buffer on the stack that may be too small for whatever goes into it. This
> can lead to crashes, or even system compromise. I am amazed that nobody
> has spotted the problem before; obviously not many people are using this
> software. :}
> 
> Anyway, I have patched things up now so that things should be ok.
> 
> Read the table below for any action that you must take if you run mathopd.
> The table informs you, for each particular version, whether it is
> vulnerable to remote exploits of this bug, and whether an upgrade exists,
> and which one you should use.
> 
> Branch/Version   Status
> ---------------------------------------------------------------------
> 1.2 and older    Probably vulnerable, not supported
> 1.3 before pl8   Probably vulnerable, upgrade advised
> 1.3pl8           Patched, otherwise not supported (use 1.4p2 instead)
> 1.4 before p2    Definitely vulnerable, upgrade immediately to 1.4p2
> 1.4p2            Not vulnerable
> 
> BETA versions:
> 
> 1.5 before b14   Vulnerable
> 1.5b14           Not vulnerable
> ---------------------------------------------------------------------
> 
> In short: all versions in the 1.3, 1.4 and current branch are fixed (at
> least for this particular problem.) If you run 1.3 at this moment, you may
> be all right, but it is probably wise to upgrade anyway. If you run 1.4
> right now you are in trouble; please upgrade as soon as possible.
> 
> The patched versions are available for immediate download on the Mathopd
> website.
> 
> Sorry about this. This has not been a good week.
> 
> Cheers
> Michiel
> 
> 
> 
> 
> 
> 
> 
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic