Re: [Fwd: Security Alert; possible buffer overflow in all Mathopd versions]
In-Reply-To: <3FD09747.7010607@xxxxxxxx>
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@xxxxxxxxxxxxxxxxx; run by ezmlm
>Precedence: bulk
>List-Id: <bugtraq.list-id.securityfocus.com>
>List-Post: <mailto:bugtraq@xxxxxxxxxxxxxxxxx>
>List-Help: <mailto:bugtraq-help@xxxxxxxxxxxxxxxxx>
>List-Unsubscribe: <mailto:bugtraq-unsubscribe@xxxxxxxxxxxxxxxxx>
>List-Subscribe: <mailto:bugtraq-subscribe@xxxxxxxxxxxxxxxxx>
>Delivered-To: mailing list bugtraq@xxxxxxxxxxxxxxxxx
>Delivered-To: moderator for bugtraq@xxxxxxxxxxxxxxxxx
>Received: (qmail 5651 invoked from network); 5 Dec 2003 14:30:23 -0000
>Message-ID: <3FD09747.7010607@xxxxxxxx>
>Date: Fri, 05 Dec 2003 15:33:43 +0100
>From: Gregor Lawatscheck <gpel@xxxxxxxx>
>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@xxxxxxxxxxxxxxxxx
>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@xxxxxxxxxx>
>To: mathopd@xxxxxxxxxxx
>
>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
>
>
>
>
>
>
>
>
>