Project

General

Profile

Bug #5844

FreeNAS default blank password

Added by Kurt Seifried over 6 years ago. Updated about 6 years ago.

Status:
Closed
Priority:
Nice to have
Assignee:
William Grzybowski
Category:
OS
Target version:
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
Yes
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:
ChangeLog Required:
No

Description

So my posting to OSS-Security (http://seclists.org/oss-sec/2014/q3/389):

So I installed the latest FreeNAS (9.2.1.7), install is simple, no
options, it just drops it onto the disk you specify, you reboot, it works.

By default you get a text based menu with some options (setup
network/DNS/etc.), and one option is "Reset WebGUI Login Credentials".

The problem is at first boot (and if you ever pick "Reset WebGUI Login
Credentials") the web admin has a blank password, anyone that can access
it can set the admin password and then use the web GUI to fire up a root
shell (there's a nice little web shell command line).

So an attacker can easily race the admin to the WebGUI, set a new
password, login as root, setup a backdoor, then reset the WebGUI
password so it's blank again and the admin would be none the wiser (log
files won't help because the attacker has root can can easily sanitize
them).

There is no way from the text GUI to set the Web GUI admin password. I
don't think there is even a CLI tool to set the web GUI password (I
can't find it easily).

Either way, does this deserve a CVE? Forcing a user to set the admin Web
GUI password through the Web GUI, meaning it must be exposed to some
degree prior to securing it. My understanding is default/blank admin
credentials now CVE. Thanks.

===========

Mitre's response (http://seclists.org/oss-sec/2014/q3/406):

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.


Subtasks

Bug #5859: New installer need to prompt for root password during installationClosedSean Fagan

Related issues

Related to FreeNAS - Bug #6152: Fix for #5844 has created an entirely new problem with unattended bootResolved2014-09-21

Associated revisions

Revision 64ff08c4 (diff)
Added by William Grzybowski over 6 years ago

Move password change procedure to bsdUsers model Ticket: #5844

Revision 883933ca (diff)
Added by William Grzybowski over 6 years ago

Change netcli to set root password instead of resetting it Ticket: #5844

History

#1 Updated by Josh Paetzel over 6 years ago

  • Status changed from Unscreened to Screened
  • Assignee set to Josh Paetzel
  • Target version set to 49

Since FreeNAS 9.3 will be install only, it seems reasonable that part of the install process will set a root password. This isn't possible with current FreeNAS versions since it can be run from an image we distribute.

Being able to set the root password from the CLI is also a reasonable FR, although that won't stop the root issue in all cases.

#2 Updated by Cyber Jock over 6 years ago

Kurt,

Your complaint is perfectly valid, kind of.

FreeNAS is designed (and it mentions in the manual) that you should be running FreeNAS from behind a firewall. Even if you set a password on install (which I believe is what you are requesting) you have other loopholes. For example, FreeNAS defaults to http when doing initial setup. This is a problem all of its own because http is in the clear. If you choose https it will be self-signed which has its own limitations. So you automatically have lost some of that "trust" in ensuring that only you control the server.

At some point you have to be willing to trust your LAN and what is going on behind a firewall to not be a significant attack vector. If your LAN is that hostile of an environment I'd argue that you have bigger problems to worry about than a FreeNAS server potentially being compromised for the few minutes between initial install and setting a password.

#3 Updated by Kurt Seifried over 6 years ago

There is a BIG difference between: "attacker must man in the middle to subvert HTTP session" (e.g. control ARP, DNS, routing or something along thos e lines) and "attacker simply connects to server, and sets themselves up as root". I can easily defend against man in the middle attacks by having a properly configured network, the complete lack of root password not so much.

#4 Updated by Josh Paetzel over 6 years ago

Kurt,

Your points are perfectly valid.

We will add the ability to set a root password during the install. This will eliminate the attack vector you are describing, and is in line with what every other OS on the planet does. :)

We will add the ability to set the root password via the CLI menu. This will allow you to bring up a FreeNAS box with no network connection, set up the root password, then bring up the network.

We will do something (not quite sure what yet) to allow HTTPS to be used from the get go if it is so desired. (HTTPS by default. Ability to switch it from the CLI menu, give the choice during install, HTTPS/HTTP by default)

#5 Updated by Kurt Seifried over 6 years ago

One suggestion on the HTTPS front, add an option to the menu, or print out the basic cert info like id and fingerprint, then when I connect to it I can confirm it's the real one. Or allow install of an HTTPS cert from CLI (using usb key to copy it over? whatever).

#6 Updated by Jordan Hubbard over 6 years ago

  • Assignee changed from Josh Paetzel to William Grzybowski

BRB: OK, so we have decided that two things need to happen:

1. During installation (unlike today) we need to prompt for the root password to use.
2. The "Reset Password" option in the Console menu needs to change to "Set Root Password" so that it's enforcing a password selection, not just blowing the old one away.

This ticket will cover task #2. Creating subtask for Sean to do #1.

We are not going to enforce HTTPS only since it opens a host of certificate management issues (clicking through a self-signed cert dialog as a general practice is really training users in the wrong way). Don't hook your FreeNAS box to an insecure network during initial setup.

#7 Updated by Jordan Hubbard over 6 years ago

  • Target version changed from 49 to 9.3-M3

#8 Updated by William Grzybowski over 6 years ago

  • Status changed from Screened to Resolved

#9 Updated by Dru Lavigne about 6 years ago

  • Status changed from Resolved to Closed

Verified in M3 and added to the 9.3 docs.

#10 Updated by Xin Li about 6 years ago

  • Related to Bug #6152: Fix for #5844 has created an entirely new problem with unattended boot added

Also available in: Atom PDF