Expired password + disabled power button design

[Joseph Reynolds]

On 9/5/19 4:02 PM, Ed Tanous wrote:
> On 9/5/19 1:19 PM, Joseph Reynolds wrote:
>> HOWEVER, there is a hole in this design which extends the time window
>> indefinitely.  The scenario begins when the installer takes possession
>> of a new system (BMC + host) and plugs it into power.  At this point,
>> the BMC starts running and offering its services to network users.
>> The host remains powered off.  The installer then disregards the BMC
>> and uses the power button to boot the host system, then continues to
>> disregard the BMC when provisioning the host, either using physical
>> access to the host (not via the BMC), or a pre-configured host.  This
>> results in a fully-functional host and a BMC which still has its
>> default password.
>> THEREFORE, I am proposing a new "disabled power button" image
>> feature.  Normally, pressing the power button tells the BMC to power
>> on and boot the host.  With this design, if the BMC still has its
>> default expired password, it will ignore a power button press, and
>> will instead indicate to the operator to configure the BMC's password,
>> and try again.  Options for the BMC to indicate this are
>> machine-specific and include: messages to an operator panel, or LED
>> blink codes.  The recovery procedure is for the installer to access
>> the BMC, change its password, and try again to power on the server.
>>
> This goes completely against one of the principals that some commercial
> products hold dear:  The BMC should NEVER be able to brick the host.
>
> In a perfect world, the BMC would never crash, get loaded with bad
> firmware or brick itself.  In practice, this is far from the case.  In
> general the primary avenue used to resolve these cases is a force
> firmware update jumper, and a download of a new (fixed) firmware via KCS
> or block transfer.  For that flow to function, the power button needs to
> work, and the host needs to boot, otherwise the board is considered
> bricked, and needs to be returned to the factory to be reflashed.
>
> With all of the above said, if it's an option that can be disabled (and
> hopefully disabled by default) I have no objection to it, but I don't
> think it's an acceptable solution for most of the BMCs out on the market
> today.
>
>
> Another option for your scenario would also be to default the BMC to a
> static IP of 0.0.0.0, and disable the NIC(s) by default.  To set up the
> network, a user would need to log into the BMC the first time over an
> in-band channel, set their password, then set up either a valid static
> IP, or DHCP.  This is how some of the more security conscious BMCs I
> know of get around this problem today.

Thanks for your reply.  That helps.  We also don't want to brick our 
systems. :-)

How likely is the scenario described in the HOWEVER clause above? To 
create this security exposure, the installer would have to connect a 
network cable to the BMC and then not access the BMC via its network 
connection.  Is that something that happens in practice?  Could this be 
mitigated by installation instructions? The installation instructions 
could state, for example, not to connect a network cable to the BMC 
unless you then change the BMC's default password.  Then to emphasize 
the point, the instructions could also state, for example, that you must 
change the BMC's default password if you connect a network cable to it.

However, this approach doesn't feel secure by default.  I understand the 
more general problem is how to securely provision your BMC. Does anyone 
know where these discussions are happening?

- Joseph