Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 16 Jun 2014 16:18:17 -0400 (EDT)
Subject: Re: CVE request: monitorix: HTTP server 'handle_request()' session fixation & XSS vulnerabilities (clearing up confusion)

Hash: SHA1

(In MITRE internal discussions, we noted that CVE mappings for the
December 2013 oss-security Monitorix thread unfortunately were not
resolved. We acknowledge that this is not a timely response.)

> Following the suggestion from Brian Martin (Open Security Foundation), I 
> write here to try to clear up things related to the latest security 
> vulnerabilities that affected the Monitorix built-in HTTP server. refers to and the first comment in
issue #30 has this quoted text:

  The remote host is running a web server that fails to adequately
  sanitize request strings of malicious JavaScript. By leveraging this
  issue, an attacker may be able to inject arbitrary cookies. Depending
  on the structure of the web application, it may be possible to launch
  a 'session fixation' attack using this mechanism.

Apparently related to this, says:

  Monitorix contains a flaw in the HTTP server's handle_request()
  function that allows a remote, user-assisted attacker to conduct
  a session fixation attack. This flaw exists because the application,
  when establishing a new session, does not invalidate an existing
  session identifier and assign a new one. With a specially crafted
  request fixating the session identifier, a context-dependent
  attacker can ensure a user authenticates with the known session
  identifier, allowing the session to be subsequently hijacked.

Looking at
suggests a stateless web application that relies on HTTP Basic
Authentication. There are no session identifiers of the type mentioned
in and we don't see a
rationale for mapping any observed Monitorix behavior to the "CWE-384:
Session Fixation" concept. also says:

  These two security vulnerabilities fixed in 3.4.0 were described as "Web 
  Server Generic Cookie Injection" and "Web Server Generic XSS"

"Cookie Injection" isn't terminology used in MITRE's CVE or CWE
project. Also,
doesn't show any use of cookies. We think that Cookie Injection means
that, if an attacker requests a URI beginning with


then the unpatched Monitorix code would have produced an HTML document
containing that SCRIPT element. In CVE's terminology and practices,
this is considered a behavior that is resultant from XSS. says:

  For the XSS issue for the PATH_INFO (aka the $url variable), fixed in
  3.4.0, use CVE-2013-7071.

The reason that we used the PATH_INFO terminology is the line "my $url
= $cgi->path_info();" in the
code. We feel that that terminology choice is not critical because
we are not going to have multiple CVEs for issues fixed in 3.4.0. also says:

  For the other issue (the unspecified issue of the "two security
  issues") fixed in 3.4.0, use CVE-2013-7072.

We will be moving CVE-2013-7072 to the "REJECT" state because that CVE
assignment came only from an interpretation of the "3.4.0 version
released" section of before that
section was rewritten. From the perspective of CVE content decisions,
there can be only one CVE assignment for what was fixed in 3.4.0. The
primary vulnerability type is XSS, and the CVE ID for that is

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