Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 19 Aug 2014 11:41:19 +0200
From: Pierre Schweitzer <>
Subject: Re: Re: FreeNAS default blank password

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"
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, 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>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
Version: GnuPG v1


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.