OpenBMC 2.8 security audit results

[Joseph Reynolds]

On 6/22/20 4:30 AM, Alexander Tereschenko wrote:
> On 20-Jun-20 03:26, Joseph Reynolds wrote:
>> Here are the results from my "security audit" on the planned OpenBMC 
>> 2.8 release.  The results are not intended as a complete analysis, 
>> but only offer highlights into the BMC's security configuration. 
>> Contributions are appreciated.
>> The script to perform these tests was presented here: 
>> https://lists.ozlabs.org/pipermail/openbmc/2020-April/021186.html and 
>> was followed more-or-less.
>>
>> $ echo "Checking test host openssl version"
>> Checking test host openssl version
>> $ openssl version
>> OpenSSL 1.0.2k-fips  26 Jan 2017
>>
> I'm not sure I get this one - is "test host" a BMC or the one where 
> the test script is being run? If the former, this is really old, no 
> longer publicly supported by the OpenSSL team and has multiple CVEs 
> against it [1], so should be upgraded.
>
> [1] https://www.openssl.org/news/openssl-1.0.2-notes.html

Alexander, thanks for your reply.  The "test host" is a Linux system 
used to probe the BMC via network interfaces such as SSH, HTTPS, and 
REST APIs.  To reflect actual customer use, I used a test host that has 
an older operating system.  I've included the test host's software 
versions to help answer questions about the results below, when the host 
version factors into the results.  [I'll update my preamble with this 
information.]

>
>
>> debug1: Remote protocol version 2.0, remote software version 
>> dropbear_2019.78
>
> There's a very recent 2020.79, which has one CVE fix and some useful 
> changes (e.g. using getrandom(), AES-GCM and so on), would be good to 
> update it for the next release.

Agreed.  Yocto will pull in the new dropbear release, and it will 
downstream to OpenBMC.  We may want to update our dropbear/options.patch

https://github.com/openbmc/openbmc/blob/master/meta-phosphor/recipes-core/dropbear/dropbear/options.patch

>
>
>> observation: The BMC SSH server offers the algorithms shown above. 
>> Should we remove HMAC-SHA1?
>
> While it's not [yet] formally broken in the HMAC setting, IMO SHA1 is 
> "broken enough" to remove it everywhere, so yes, I'd vote for that.
>
>
>>
>> When logged into the BMC via SSH as testuser:
>> testuser$ ls -la /home/root
>> drwxr-xr-x    2 root     root           384 Jun 18 00:00 .
>> drwxr-xr-x    5 root     root           368 Jun 20 00:23 ..
>> -rw-------    1 root     root         12437 Jun 20 00:24 .bash_history
>> -rw-r-----    1 root     root           459 Jun 19 20:19 
>> bmcweb_persistent_data.json
>>
>> observation: Non-root user can list files in /home/root; that seems 
>> undesireable.  The files themselves are not readable.
>
> Agree, it doesn't seem necessary, so should be restricted
>
>
>> /etc/ssl/certs:
>> drwx------    2 root     root           160 Jun 10 06:22 authority
>> drwx------    2 root     root           304 Jun 10 06:23 https
>>
>> observation: Certificates under /etc/ssl are protected from reading
>
> This actually seems to be surplus - *certificates* are public by 
> definition, it's the private parts of them (private keys corresponding 
> to public ones in certificates) that need protection like that.

Thanks for the clarification.  I've heard a private certificate is 
improperly being stored along with its public cert in there somewhere, 
but I don't really know.

>
>
> regards,
> Alexander
>