[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