Date: Tue, 10 Dec 2013 19:08:13 +0000 From: George Theall <gtheall@...able.com> To: "<oss-security@...ts.openwall.com>" <oss-security@...ts.openwall.com> CC: "ratulg@...hat.com" <ratulg@...hat.com>, "cve-assign@...re.org" <cve-assign@...re.org> Subject: Re: Re: CVE request: monitorix: HTTP server 'handle_request()' session fixation & XSS vulnerabilities On Dec 10, 2013, at 12:35 PM, <cve-assign@...re.org> <cve-assign@...re.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Yes, we recognize that http://secunia.com/advisories/55857/ is an > additional reference. Relative to what we previously posted, existence > of this reference does not simplify the situation, because it says > "Two vulnerabilities have been reported" and then perhaps proceeds to > state what only one of the vulnerabilities is. Or, alternatively, > maybe that Secunia advisory is implicitly categorizing $target and > $target_cgi as separate vulnerabilities. > > Does anyone wish to contribute the information about whether the first > problem fix (involving allowable characters in the $target and > $target_cgi variables in lib/HTTPServer.pm) was part of 3.3.1, or only > part of 3.4.0? If not, we can have someone at MITRE try to locate a > copy of 3.3.1 later. Older releases of Monitorix are available from http://www.monitorix.org/old_versions/ , and browsing the source for 3.3.1, you will find the commit from https://github.com/mikaku/Monitorix/commit/ff80441be7089f774448dfe4b49e6fced70e71cb is indeed included in that, as reflected in both the ‘Changes’ and ‘lib/HTTPServer.pm’ files. > > https://github.com/mikaku/Monitorix/blob/master/Changes says > > Fixed to correctly sanitize the input string in the built-in HTTP server > which led into a number of security vulnerabilities. [#30] > > in both the 3.3.1 and 3.4.0 changelog entries. Also, as we previously > posted, the vendor referred to "two security issues ... not covered > yet in the previous 3.3.1 version" when announcing 3.4.0. We see that > there is a second XSS-related commit involving the PATH_INFO (aka the > $url variable) but this isn't necessarily "two security issues" by > itself. So, we still don't know how many CVE IDs to assign, and we > would prefer not to assign any CVE IDs until the meaning and scope of > each ID is at least somewhat understood. > > - -- > 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) > > iQEcBAEBAgAGBQJSp1A6AAoJEKllVAevmvmstTsH/iCuzA8UqbTbMQCYQ7PfNFE5 > O0uYBMLgjBq801xz+aLF0FIhlm6Ruac3qfi7pXv+CV9OgtcHqoOuLTsnrUM4vNi/ > dCH5o3l+5aD4DMasP/Q8upSwqJl8GgUhyr78lgNRUxA/Wdje6o4+HM/v7lLLr6Hf > uWLWndMzSzDw79R3RChz4cnXhDRYrSesBEDGdwFwN4/wRQ4Tp9WX3ocRGvhxw1fk > 5yo789nJzL3jYhXczqcUUR50OBQREUmB7eF1Kt4wU0idumaAm3mWARxnaWoA5Xgu > dEyHhaNpu/uml4m1NswPmar9L1hh2kOORAmoY5KyhH6y2UIPmQDEKEcSX8tenPY= > =JnLr > -----END PGP SIGNATURE----- George -- theall@...able.com
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.