NetBSD Problem Report #54080

From he@smistad.uninett.no  Tue Mar 26 15:55:05 2019
Return-Path: <he@smistad.uninett.no>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id CA5A57A15D
	for <gnats-bugs@gnats.NetBSD.org>; Tue, 26 Mar 2019 15:55:05 +0000 (UTC)
Message-Id: <20190326155500.55AA443F3EC@smistad.uninett.no>
Date: Tue, 26 Mar 2019 16:55:00 +0100 (CET)
From: he@uninett.no
Reply-To: he@uninett.no
To: gnats-bugs@NetBSD.org
Subject: bozohttpd prone to null pointer de-reference (SEGV)
X-Send-Pr-Version: 3.95

>Number:         54080
>Category:       bin
>Synopsis:       bozohttpd prone to null pointer de-reference (SEGV)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Mar 26 16:00:00 +0000 2019
>Closed-Date:    Tue Aug 24 05:30:31 +0000 2021
>Last-Modified:  Tue Aug 24 05:30:31 +0000 2021
>Originator:     he@uninett.no
>Release:        NetBSD 8.0
>Organization:
	Uninett AS
>Environment:
System: NetBSD xxxx.uninett.no 8.0 NetBSD 8.0 (GENERIC) #0: Sun Aug 5 00:07:14 CEST 2018 he@uninett.no:/usr/obj/sys/arch/amd64/compile/GENERIC amd64
Architecture: x86_64
Machine: amd64
>Description:

	I have a bozohttpd running on one of my hosts exposed to the
	internet at large, and recently noticed in the log that
	bozohttpd had crashed several times with SEGV.  Inspecting the
	core dump gave me:

# gdb -q /usr/obj/libexec/httpd/bozohttpd.debug /home/he/html/bozohttpd.core
Reading symbols from /usr/obj/libexec/httpd/bozohttpd.debug...done.
[New process 1]
Core was generated by `bozohttpd'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  bozo_http_error (httpd=0x7f7fff0e1ea0, code=408, request=0x0, 
    msg=<optimized out>) at /usr/src/libexec/httpd/bozohttpd.c:2253
2253            if (code == 408 && request->hr_proto == httpd->consts.http_11)
(gdb) where
#0  bozo_http_error (httpd=0x7f7fff0e1ea0, code=408, request=0x0, 
    msg=<optimized out>) at /usr/src/libexec/httpd/bozohttpd.c:2253
#1  0x000070e36ccc047a in ?? ()
#2  0x8080808080808080 in ?? ()
#3  0x0000000000000000 in ?? ()
(gdb) l
2248            bozo_printf(httpd, "Content-Length: %d\r\n", size);
2249            bozo_printf(httpd, "Server: %s\r\n", httpd->server_software);
2250            if (request && request->hr_allow)
2251                    bozo_printf(httpd, "Allow: %s\r\n", request->hr_allow);
2252            /* RFC 7231 (HTTP/1.1) 6.5.7 */
2253            if (code == 408 && request->hr_proto == httpd->consts.http_11)
2254                    bozo_printf(httpd, "Connection: close\r\n");
2255            bozo_printf(httpd, "\r\n");
2256            /* According to the RFC 2616 sec. 9.4 HEAD method MUST NOT return a
2257             * message-body in the response */
(gdb) p request
$1 = (bozo_httpreq_t *) 0x0
(gdb) 

	Several other tests in this code (even visible in the list
	window) tests whether "request" is non-NULL, but not this
	particular piece of code...

>How-To-Repeat:
	Deploy an exposed bozohttpd and watch it sometimes crash.
	(I'm sure it's being "mis-used" protocol-wise, but that should
	not cause it to fall over.)

>Fix:
	Introduce a test of "request", but don't know what to do if it
	is NULL, so no code suggestion here...



>Release-Note:

>Audit-Trail:

State-Changed-From-To: open->needs-pullups
State-Changed-By: leot@NetBSD.org
State-Changed-When: Tue, 26 Mar 2019 16:34:46 +0000
State-Changed-Why:
Fixed in src/libexec/httpd/bozohttpd.c,-r1.104 but needs
to be pulled up.


From: Leonardo Taccari <leot@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/54080: bozohttpd prone to null pointer de-reference (SEGV)
Date: Tue, 26 Mar 2019 17:30:54 +0100

 Hello he!

 he@uninett.no writes:
 > [...]
 > >Description:
 >
 > 	I have a bozohttpd running on one of my hosts exposed to the
 > 	internet at large, and recently noticed in the log that
 > 	bozohttpd had crashed several times with SEGV.  Inspecting the
 > 	core dump gave me:
 >
 > # gdb -q /usr/obj/libexec/httpd/bozohttpd.debug /home/he/html/bozohttpd.=
 core
 > Reading symbols from /usr/obj/libexec/httpd/bozohttpd.debug...done.
 > [New process 1]
 > Core was generated by `bozohttpd'.
 > Program terminated with signal SIGSEGV, Segmentation fault.
 > #0  bozo_http_error (httpd=3D0x7f7fff0e1ea0, code=3D408, request=3D0x0, =

 >     msg=3D<optimized out>) at /usr/src/libexec/httpd/bozohttpd.c:2253
 > 2253            if (code =3D=3D 408 && request->hr_proto =3D=3D httpd->c=
 onsts.http_11)
 > (gdb) where
 > #0  bozo_http_error (httpd=3D0x7f7fff0e1ea0, code=3D408, request=3D0x0, =

 >     msg=3D<optimized out>) at /usr/src/libexec/httpd/bozohttpd.c:2253
 > #1  0x000070e36ccc047a in ?? ()
 > #2  0x8080808080808080 in ?? ()
 > #3  0x0000000000000000 in ?? ()
 > (gdb) l
 > 2248            bozo_printf(httpd, "Content-Length: %d\r\n", size);
 > 2249            bozo_printf(httpd, "Server: %s\r\n", httpd->server_softw=
 are);
 > 2250            if (request && request->hr_allow)
 > 2251                    bozo_printf(httpd, "Allow: %s\r\n", request->hr_=
 allow);
 > 2252            /* RFC 7231 (HTTP/1.1) 6.5.7 */
 > 2253            if (code =3D=3D 408 && request->hr_proto =3D=3D httpd->c=
 onsts.http_11)
 > 2254                    bozo_printf(httpd, "Connection: close\r\n");
 > 2255            bozo_printf(httpd, "\r\n");
 > 2256            /* According to the RFC 2616 sec. 9.4 HEAD method MUST N=
 OT return a
 > 2257             * message-body in the response */
 > (gdb) p request
 > $1 =3D (bozo_httpreq_t *) 0x0
 > (gdb) =

 >
 > 	Several other tests in this code (even visible in the list
 > 	window) tests whether "request" is non-NULL, but not this
 > 	particular piece of code...
 >
 > >How-To-Repeat:
 > 	Deploy an exposed bozohttpd and watch it sometimes crash.
 > 	(I'm sure it's being "mis-used" protocol-wise, but that should
 > 	not cause it to fall over.)
 >
 > >Fix:
 > 	Introduce a test of "request", but don't know what to do if it
 > 	is NULL, so no code suggestion here...
 > [...]

 This was privately spotted by <maya> and fixed in
 src/libexec/httpd/bozohttpd.c,-r1.104 (that just check for `request'
 before dereferencing it as you have proposed.)

 (But unfortunately never pulled up.)

From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, he@uninett.no
Subject: re: bin/54080: bozohttpd prone to null pointer de-reference (SEGV)
Date: Wed, 27 Mar 2019 04:58:52 +1100

 >  This was privately spotted by <maya> and fixed in
 >  src/libexec/httpd/bozohttpd.c,-r1.104 (that just check for `request'
 >  before dereferencing it as you have proposed.)
 >  
 >  (But unfortunately never pulled up.)

 hmmm, yeah, it was sync across branches in november.  i'll see
 about sending an update to all branches.

 thanks.


 .mrg.

State-Changed-From-To: needs-pullups->feedback
State-Changed-By: leot@NetBSD.org
State-Changed-When: Wed, 12 Jun 2019 10:44:05 +0000
State-Changed-Why:
Pulled up to netbsd-8 via ticket #1281.

he, can you please retry and let us known if the problem
is fixed?

Thank you!


State-Changed-From-To: feedback->closed
State-Changed-By: mrg@NetBSD.org
State-Changed-When: Tue, 24 Aug 2021 05:30:31 +0000
State-Changed-Why:
feedback timeout. thanks.


>Unformatted:

Home	PR Database Search