[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20150510160932.68C193321CE@smtpvbsrv1.mitre.org>
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.
