Date: Sun, 10 May 2015 12:09:32 -0400 (EDT) From: cve-assign@...re.org To: kash@...pleback.net Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: CVE for Jentu -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > There are multiple vulnerabilities: > * Client servers do not do certificate validation against the Jentu server Often this is a vulnerability that can have a CVE, but not always. Can you explain more about this, e.g., does one server confirm the integrity of another server's data in a different way, making certificate validation unnecessary? Is it plausible that "client servers" and "the Jentu server" communicate over an untrusted network? Are the terms "client servers" and "the Jentu server" related to anything on the jentu.net web site, e.g., "master server" and "slave servers"? > * The web UI connection to the client server is restricted to only allow > "localhost" to connect, however, forged packets will allow an attacker > to execute arbitrary code as the www-data user on Linux (or www user on > FreeBSD). Because lighttpd is operating with sudo access to your entire > ZFS pool, the amount of damage that can be caused is huge. Why is this a vulnerability in the Jentu product? Would this issue normally be addressed by a host-based firewall that drops packets with (for example) 127.0.0.0/8 source IP addresses if they arrive from a non-localhost interface? Is the threat only from local users on a "client server" machine, e.g., are you suggesting that use of IP is inherently wrong and a different choice (such as a UNIX domain socket) should have been adopted instead? > * Jentu uses ZFS on Linux that currently lacks a working "zfs allow" > security interface, requiring lighttpd to have root access to certain > ZFS binaries with little (if any) command sanitization. Do you mean that the system architecture was designed on the basis that privilege escalation to root (from the account under which lighttpd is running) is not a threat that is intended to be addressed? Or do you mean that command sanitization is either partially implemented, or at least implied by documentation, but that the command sanitization was done incompletely? > * DNS rebinding attacks are possible against the client server, causing > DoS or even privilege escalation when combined with local iSCSI station > exploits: As the user browses to http://hackedsite.com which requests an > AJAX call to http://defaultgateway/clone.php?mac=00-11-22-33-44-55 where > 00-11-22-33-44-55 is the MAC of the victim machine. It is often difficult to assign CVE IDs based on an "attacks are possible" report. Is there a specific vulnerability in the Jentu code that is being reported here? For example, do you mean that it is impossible to use Jentu safely because validating the Host HTTP header was a design requirement, and this requirement was never implemented? Or do you mean that Jentu should have shipped with a deployment note about the DNS rebinding risk, perhaps stating that Jentu be deployed with internal IP addresses, and a DNS architecture that prevents a user from encountering a mapping from an arbitrary DNS name (such as hackedsite.com) to one of these internal IP addresses? > * The local iSCSI server, iscsitarget (iet) runs in "permissive" mode > that allows any one of the iSCSI systems on the network to connect to > and manipulate any other iSCSI target for unrelated systems. Is this an implementation flaw, e.g., use of "permissive" mode was completely unnecessary and the Jentu product should have been shipped with a different mode? Or are you suggesting that this, although often unsafe, is an inherent part of the design -- in other words, the documentation failed to mention an expectation of mutual trust among the iSCSI systems on the network? - -- 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) iQEcBAEBAgAGBQJVT4ISAAoJEKllVAevmvmsUZcH/Au0szO94oYvUy0yIzsU+8mf Fzdi44gxq2+AhjNYAQKau1XO+sHSvWUSHs6EULKnk4KsCz3v+9ZEWPD7T04Vys05 Y362oTQbphLNl2oKx06nmO7eZGAPmygr258OLF1wzV9zcmsfNM8lLSO3fBCrhDsq I645I+TdnipAK/iTbFwChS9gYw26PfFz+SzG31ViVAxzzzTCzl+/7p1olOfrVpEM +AeRCcGeUP/DB0oZognWXMNZA5cTuMWPEVjZ7A85OyYTpF+LRDBWhKu1/N3qsv7s d3ZsaitZkeudA8gS1wwNdzJPjs2aBy/opAyky+l3VS4qHuaNK1NIhU40DE2jqL8= =BCyv -----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.