Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 21 May 2014 23:41:23 -0400 (EDT)
Subject: Re: CVE request, multiple vulnerabilities in openwsman

Hash: SHA1


> A recent security code review was performed on openwsman version 2.4.3
> and several issues were identified and fixed in version 2.4.4.
> Can we please get CVEs assigned to them?

There isn't enough information in this request. These commit messages
don't describe how an attack can occur that crosses privilege
boundaries, or explain why the apparently mishandled data comes from
an untrusted source. A CVE ID can't be assigned solely on the basis of
locating code that is potentially unsafe or simply wrong. For example,
we don't assign CVE IDs on the basis of output produced by the
Coverity Scan service, and we also don't assign CVE IDs on the basis
of similar detail generated in a manual review.

At this point, we aren't going to comment separately on each of the
commits but here are some initial observations:

  char buf[20];
  sprintf(buf, "PT%fS", options->expires);


  snprintf(buf, 20, "PT%fS", options->expires);

The source code says "unsigned long expires; // expiration time in
msecs since the epoch." Are there values of options->expires that can
occur, but result in too many characters with the format string? If
so, would it make sense to reject those options->expires values, or
use a larger buffer, instead of using snprintf with the same buffer
size as before?

The filename is src/lib/wsman-client.c. Would this typically be used
only by a client application, e.g., an application that calls the
wsman_create_client function? Are there realistic use cases in which
the expires value is untrusted: for example, it originates in a web
form, or the application is installed setuid and can be executed by
unprivileged users? In other words, can untrusted input be used for
privilege escalation, or in a denial of service attack affecting a
client that was supposed to remain running for additional users?

Does this depend on misconfiguration, or is it exploitable by an
attacker against a realistic installation of the product? In other
words, is the essential problem that, if the product or machine is
misconfigured so that required repository pathnames don't exist or
have permission problems, then an application could crash?

Does this mean that the product would realistically be reading an
attacker-controlled XML document, and could crash?

  char *subcode_value = ws_xml_get_xpath_value(doc, FAULT_SUBCODE_VALUE_XPATH);
  if (strlen(subcode_value) == 0)

Can a zero-length return value occur?

The source code has:

  char *ws_xml_get_xpath_value(WsXmlDocH doc, char *expression)
          return xml_parser_get_xpath_value(doc, expression);

  char *xml_parser_get_xpath_value(WsXmlDocH doc, const char *expression)
  return NULL;

Given that the function's return value can be NULL, why does the
patched code still call strlen on this value?

- -- 
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.