Bugtraq mailing list archives

Re: [Fwd: Security Alert; possible buffer overflow in all Mathopd versions]


From: Peter Geissler <blasty () geekz nl>
Date: 8 Dec 2003 07:44:01 -0000

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











Current thread: