OpenBMC 2.8 security audit results

[Alexander Tereschenko]

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


> 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.


> 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.


regards,
Alexander