Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20150315042616.DE2A46C0005@smtpvmsrv1.mitre.org>
Date: Sun, 15 Mar 2015 00:26:16 -0400 (EDT)
From: cve-assign@...re.org
To: blinken@...il.com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: CVE request: vulnerabilities in libcsoap

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> * Remote null pointer dereference
> A remote user can cause a null pointer dereference by sending a
> malformed Authorization: header.
> http://patrick.ld.net.au/libcsoap/nanohttp-nullp-1.patch

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.
> http://patrick.ld.net.au/libcsoap/nanohttp-buffer-1.patch

First, this doesn't seem to be a new discovery.
http://csoap.sourceforge.net/downloads.php links to
http://csoap.sourceforge.net/downloads/libsoap-snapshot.tar.gz 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 http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)

iQEcBAEBAgAGBQJVBQjcAAoJEKllVAevmvmszCkH/Rcxdhsn/4nFu1YT/VJft2dH
kowC3v3ryXUjsRTJJPcg+wi7MDwSYDPuywl0CFHnlkYoI5VoLDnQMt10FL/JP7QK
5kasChItF2w+luT1Zm7UXZKXJ1w5CadfGyt8SCp4IZKDFxlVwFd0rcH/sVaOeVYg
AbAM6HE9jwgKl+1P6azbr7NjxDbt5banwiXrRIL7ffmP/JcRxn6oAacQwJNRasrW
rLO3MBhqwEpXJvs8ISZL7Kjcz5uZd7YPnZZBGcDEpvl9q6a3AittinNiXqP7lHUV
CUOKGci3AehDvGf59CIVqAyLbcPF32tmwwfRKhuv5JqMyhp+xTmI1UGRx+8BPdw=
=xgNk
-----END PGP SIGNATURE-----

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.