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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: 8 Dec 2003 07:44:01 -0000
From: Peter Geissler <blasty@...kz.nl>
To: bugtraq@...urityfocus.com
Subject: Re: [Fwd: Security Alert; possible buffer overflow in all Mathopd
    versions]


In-Reply-To: <3FD09747.7010607@...x.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@...urityfocus.com; run by ezmlm
>Precedence: bulk
>List-Id: <bugtraq.list-id.securityfocus.com>
>List-Post: <mailto:bugtraq@...urityfocus.com>
>List-Help: <mailto:bugtraq-help@...urityfocus.com>
>List-Unsubscribe: <mailto:bugtraq-unsubscribe@...urityfocus.com>
>List-Subscribe: <mailto:bugtraq-subscribe@...urityfocus.com>
>Delivered-To: mailing list bugtraq@...urityfocus.com
>Delivered-To: moderator for bugtraq@...urityfocus.com
>Received: (qmail 5651 invoked from network); 5 Dec 2003 14:30:23 -0000
>Message-ID: <3FD09747.7010607@...x.net>
>Date: Fri, 05 Dec 2003 15:33:43 +0100
>From: Gregor Lawatscheck <gpel@...x.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@...urityfocus.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@...and.org>
>To: mathopd@...hopd.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
>
>
>
>
>
>
>
>
>