Begin forwarded message: From: cve-assign@mitre.org Subject: Re: CVE Requests Date: November 7, 2014 at 4:22:16 PM EST To: larry0@me.com Cc: cve-assign@mitre.org Signed PGP part > I wanted to have CVE's assigned to this before I sent it to the lists. > Attachment: XClonerv3.1.1Pluginvulnerabilities-5.pdf > 1. Arbitrary command execution. Use CVE-2014-8603 for this issue involving shell metacharacters in an input field, such as the "Please choose your backup name" field. > 2. Clear text MySQL password exposure through html text box under configuration panel. Use CVE-2014-8604. > 3. Database backups exposed to local users due to open file permissions. For our analysis, this was the most complex part of the report. The documentation that you quoted mentioned "Don't forget to create the 'administrator/backups' directory in your Wordpress root and make it fully writeable." This suggests that the design of XCloner might not be intended to address the case of untrusted local users. Here, "fully writeable" would typically imply (to a non-expert user) mode 0777. That would, for example, let local users delete backup files. Obviously the file permissions could be 0600 even if the directory permissions are 0777, but still "fully writeable" arguably implies that the vendor was intentionally not addressing a threat model involving local attackers. If there is other applicable documentation, e.g., if the user is told to ensure that any other XCloner file is "owner www-data, mode 0600" and not "owner www-data, mode 0644" please let us know. Otherwise, our inclination is to skip the CVE assignment for this one, on the basis that it's a security-hardening recommendation and not a vulnerability finding (with respect to available information from the vendor). > 4. Unauthenticated remote access to backup files via easily guessable file names. Use CVE-2014-8605. > 5. Authenticated remote file access. Use CVE-2014-8606 for this directory traversal issue. > 6. MySQL password exposed to process table. Use CVE-2014-8607. Incidentally, sending a report to cve-assign@mitre.org and also posting http://openwall.com/lists/oss-security/2014/11/06/1 doesn't interact well with our current process for CVE assignment. The main issue is that the former was in PDF format whereas the latter was in text format, and thus there was no simple way to determine if all of the information in one format is identical to all of the information in the other format. Also, http://openwall.com/lists/oss-security/2014/11/06/1 is visible to everyone on our team, whereas the cve-assign@mitre.org e-mail messages are visible to only a small fraction of our team, and we don't have a 100% solution on our end to prevent duplication of effort. We obviously can't control when a public disclosure will occur -- even if a disclosure date is predicted, almost everyone accepts a principle of "forced disclosure" if the vulnerability details started to become public anyway (e.g., public patches by a vendor, etc.). For now, it'd be very helpful for you to mention whether future vulnerability reports sent to cve-assign@mitre.org overlap public disclosures. In other words, we would use this information to more quickly reach conclusions such as: "http://openwall.com/lists/oss-security/2014/11/06/1 is the text format for exactly the same disclosure that was already sent or posted as a PDF. MITRE doesn't need to assign staff to determine whether one of the formats mentions a vulnerability detail that the other doesn't mention." -- 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 ]