[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <53F31BBF.4050003@reactos.org>
Date: Tue, 19 Aug 2014 11:41:19 +0200
From: Pierre Schweitzer <pierre@...ctos.org>
To: oss-security@...ts.openwall.com
Subject: Re: Re: FreeNAS default blank password
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In such situation, we can then also wonder about other software such as
Icinga-web, where installation comes with default username and password
(properly documented). Be it using packages or "mainstream"
installation:
https://wiki.icinga.org/display/howtos/Setting+up+Icinga+Web+on+Ubuntu.
Such credentials give full access (root access) to the installation.
If Icinga wasn't configured yet, it's not such a drama, but otherwise,
it can become rather critical:
- -> Access to the whole infrastructure schema
- -> Possibility to submit checks which can help to harass a host/service
- -> Possibility to disable all the checks around to shut monitoring down
- -> Possibility to overload the master host by issuing too many checks
(master needs to handle them - MySQL dump, pnp4nagios, perf data
analysis, and so on)
On 19/08/2014 10:46, cve-assign@...re.org wrote:
> > My understanding is default/blank admin credentials now == CVE
>
> There isn't a precise rule of this type. For example, there may be
> situations in which the blank credentials can only be entered over a
> trusted interface (for some definition of "trusted" that is consistent
> with the vendor's security policy and otherwise reasonable for the
> product's context).
>
> > So an attacker can easily race the admin to the WebGUI, set a new
> > password
>
> Similarly, "race the admin to the WebGUI" situations don't always
> qualify for CVE IDs. There are many products in which the full
> functionality of install.php is available to the first client who
> visits install.php. A product can have a design constraint that
> installation must not require the person to have any ability to use a
> command line (or other non-browser method) for any part of the initial
> product setup. This design constraint was historically reasonable for
> some types of shared web hosting, for example.
>
> For this FreeNAS case, the blank password seems unreasonable because
>
> -- the requirement for a reboot implies that the product is not
> intended for use in constrained scenarios such as shared web
> hosting
>
> -- the web interface exposes a root shell. This is quite different
> from a case where use of install.php has a consequence limited to
> "the machine ends up with a web application that wasn't supposed
> to be there, and maybe some disk consumption or other minor
> resource consumption."
>
> Use CVE-2014-5334.
>
- --
Pierre Schweitzer <pierre at reactos.org>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJT8xu+AAoJEHVFVWw9WFsLa6cP/RIPZmZF7FU0cfSpfPjf4mlR
5RcLNefjBlOGQrQE+0se77UOvkOPU8AHgD9jSFkDaqYrn2M/kNQb6/3hvSA34kcx
Ew2vHJ3skfEo0upSwuEvb34FEZ3FeQOwTqeRy7cizCqIUojmN1mSHWPWFlADWEWY
ALbVbnrFEYCfbco1T0JKMIe85OnjKXAstCnrJaahw0eefv7nYqBv/Lf0TBWRcfHF
UO3+n2yk/W+TaVR4PTL/Rz/jNGvQOk9obfMEPRZQ6gqBTFlJO5EaN9DSrCwN2/Qw
FNSstXMoAeFEokv1Og9/Pct0eucR11GzxwO+COkCKm3/5laFgzuEOLc3KnRBdHop
a/jSDTMcrhWI3uUCQBodvRu09TWw4fSOBMGpPLe8KsNFFTQUdoMGNxIpCkVpEmOF
cpJJ7yc1zREp7RoHJrvimw+OBa82Lprffvnqu4MKsyIu57i8jpaE9tsY0WdVqa1c
WRbtlykhKW1dwRxtRZHSrCTJm3HMEYW7j/qdKDjmxtydDuJ+G7cjHCkypGA0sRPZ
3/p5gkl8QSt5nv9Gk5uFS3zQHou8ramg46R3TNOA4oeQwEIGjGpjCA7jQDyW4Cs9
9D9WVAg0qHES/wbSI6CsA7hOayCAPRMKgsiPx5Q6DrnOzeOs50w3XIVBjwo7JLNf
pvhelZjoKp+1WhXHBQnP
=b+iT
-----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.
