Security Working Group - Wednesday May 12 - results

[Andrew Jeffery]

Hi Joseph,

It tends to be useful to Cc the developers doing the work. Posting to 
the list without Cc'ing relevant people leaves discovery of your 
discussion to chance, where as adding them on To: or Cc: does two 
things:

1. Raises the chance that they'll pay attention to your discussion
2. Removes the impression that you're intentionally talking past them

Please try to engage the relevant people directly in the discussion by 
adding them in To: or Cc.

On Thu, 13 May 2021, at 03:48, Joseph Reynolds wrote:
> On 5/11/21 8:59 PM, Joseph Reynolds wrote:
> > This is a reminder of the OpenBMC Security Working Group meeting 
> > scheduled for this Wednesday May 12 at 10:00am PDT.
> >
> > We'll discuss the following items on the agenda 
> > <https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI/edit>, 
> > and anything else that comes up:
> >
> 
> Three items were discussed.  You might want to start with item 3 first 
> to introduce the first two.  Summary:
> 
> 1. Security impacts of enabling kexec (load and optionally execute new 
> kernel) in the BMC's production kernel.  How does this work and play 
> with secure boot and with IMA?

Have you engaged with OpenBMC's kernel developers? They might be are 
interested in this problem. I'm vaguely aware of some work-in-progress 
patches that allows kexec to load FIT images, which can be signed and 
validated. This would mitigate execution of arbitrary kernels and also 
helps avoid the problem of shipping multiple kernel binaries or 
extracting artefacts from a FIT to pass to kexec.

> 
> 2. What are the security impacts of having the proc file system file 
> /proc/sysrq-triggerwhich can cause kernel panics which can cause the BMC 
> to terminate processing?
> 
> 3. In general, how can you (an operator or the BMC's host system) 
> recover a BMC which has become unresponsive, for example, because its 
> kernel processing has failed.  A design introduces using 
> /proc/sysrq-triggertogether with a recovery kernel installed by kexec.

To be clear, the use of /proc/sysrq-trigger is a temporary hack to 
reboot the BMC in the absence of kexec/kdump. Once those features are 
merged the application implementing this behaviour can invoke kexec 
directly. The slight advantage of /proc/sysrq-trigger is that with or 
without kexec/kdump enabled the BMC will reboot, and if kexec/kdump are 
enabled then it will automatically take advantage of them.

In the specific case p10bmc platforms the host has access to a GPIO 
tied to the BMC's EXTRST line, so with or without this software feature 
the host can mount denial of service attacks of arbitrary length. This 
hardware design places the BMC and host firmware in the same trust 
domain.

Andrew