Potential high risk for readonly/operator users on BMC console access

Joseph Reynolds jrey at linux.ibm.com
Fri Dec 2 07:42:00 AEDT 2022


On 11/29/22 4:06 AM, Thang Nguyen OS wrote:
> Thanks for your feedback.
>
>> On 29 Nov 2022, at 08:41, Joseph Reynolds <jrey at linux.ibm.com> wrote:
>>
>> [EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please be mindful of safe email handling and proprietary information protection practices.]
>>
>>
>> On 11/21/22 4:17 AM, Thang Nguyen OS wrote:
>>> Hi,
>>> I would like to have your comments on below issue which we think it is high risk security issue which description below:
>>>
>>> Any user (read-only, operator, administrator), when created, has BMC console access/login by default. He can login to BMC via BMC console and do the following actions:
>>>   - Write to his /home/<user> folder to full. This will make the RootFS full and no more operation can be done, unless do A/C power and reflash the BMC from u-boot.
>>> - Write to /tmp folder to full which will make many application fail to work.
>>> It is good for administrator as he should have full privilege. However, for readonly/operator users, he should not have console access. No matter if he makes the BMC crashed by mistake or it is his intention, we should prevent his happens.
>>> It is known that many production systems do not support BMC console but still have some support and some companies allow remote access via KVM or console server. I think we should disable shell login for normal users (readonly and operator) by default.
>> Thanks for your report.  Here are my thoughts.
>>
>> You are describing resource exhaustion, sometimes denoted as one of:
>> - CWE-400: Uncontrolled Resource Consumption
>> - CWE-770: Allocation of Resources Without Limits or Throttling
>>
>> I agree this will lead to the failure of various BMC functions leading
>> to denial of service.
>>
>> There are two ways to access the BMC command shell:
>>
>> 1. Access to the BMC command shell via SSH port 22.  The default BMC
>> configuration only allows Administrator users to have access. [footnote 1]
> No problem with SSH. Operator and read-only users can’t access BMC shell over SSH
>> 2. Access to the BMC command shell via the BMC's serial port.  The
>> typical BMC setup either does not have a console or specifies that
>> access to the BMC's physical console port should be protected.
>>
>> Please see some related build-time configuration options here:
>> https://github.com/openbmc/openbmc/wiki/Configuration-guide#bmc-console-shell-access
>>
>> Also, we can consider adding a check so that only admin users are
>> allowed to access to a BMC command shell via the BMC's serial console.
>> (And non-admin user will be logged off.)
> Do you think we should disable console access by setting from phosphor-user-manager during user creation? The alternative command from BMC shell is usermode <user> -s /sbin/nologin

I believe all non-admin users have their default shell set to 
/bin/nologin per code in phosphor user manager:
https://github.com/openbmc/phosphor-user-manager/blob/master/user_mgr.cpp
Search for "nologin".

When reading this code, not only priv-admin users will have the "ssh" 
group role per
https://github.com/openbmc/docs/blob/master/architecture/user-management.md#supported-group-roles

Joseph


> - Joseph
>
>
> Footnote 1:
> The effect of the following is to configure the dropbear SSH server so
> only users who are in the priv-admin Linux group are allowed to connect
> via SSH.
> This config parameter:
> https://github.com/openbmc/openbmc/blob/master/meta-phosphor/recipes-core/dropbear/dropbear/dropbear.default
> Is configured into the image from here:
> https://github.com/openbmc/openbmc/blob/master/meta-phosphor/recipes-core/dropbear/dropbear_%25.bbappend
> and is used on the dropbear command line from here:
> https://github.com/openbmc/openbmc/blob/master/poky/meta/recipes-core/dropbear/dropbear/dropbear%40.service
>
>
>
>
>>> Thanks,
>>> Thang Q. Nguyen -



More information about the openbmc mailing list