Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 15 Mar 2015 00:26:16 -0400 (EDT)
Subject: Re: CVE request: vulnerabilities in libcsoap

Hash: SHA1

> * Remote null pointer dereference
> A remote user can cause a null pointer dereference by sending a
> malformed Authorization: header.

Use CVE-2015-2297 for (only) this null pointer dereference.

> * Remote buffer overflow
> If the server is misconfigured, a remote user can trigger a buffer
> overflow by requesting a resource of a certain length.

First, this doesn't seem to be a new discovery. links to and
this contains a libsoap-20070125 top-level directory with a
nanohttp/nanohttp-server.c file dated 2007-01-01. This file apparently
has the bug fixed in a (very) slightly different way:

   char buffer[256];
   snprintf(buffer, 256, "service '%s' is not registered properly (service function is NULL)", req->path);

More importantly, we haven't been able to find any indication that
this issue is within the scope of CVE. As far as we can tell, building
libcsoap does not create a sample HTTP server. If someone writes their
own application to create an HTTP server, the "else" code path after
"if (service->func != NULL)" should always be unreachable. If this
code path is reachable, that's a bug in their application and
therefore a site-specific problem. Unless the upstream vendor has
stated something else, the behavior of the library is undefined if the
application is wrong. If the actual behavior is a remote buffer
overflow, that's within the bounds of undefined behavior. We don't
feel that there are required security properties for a code path
that's not reachable in any supported or reasonable use of a library.

Also, we don't think it's especially likely that someone would write
an application in which service->func can ever be NULL. For example,
libsoap-20070125 has a nanohttp-admin.c file in which service->func is
always the _httpd_admin_entry function.

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through ]
Version: GnuPG v1.4.14 (SunOS)


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.