Security Working Group meeting - Wednesday October 13

Security Working Group meeting - Wednesday October 13

[Joseph Reynolds]

This is a reminder of the OpenBMC Security Working Group meeting 
scheduled for this Wednesday October 13 at 10:00am PDT.

We'll discuss the following items on the agenda 
<https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI>, 
and anything else that comes up:

1.



Access, agenda and notes are in the wiki:
https://github.com/openbmc/openbmc/wiki/Security-working-group 
<https://github.com/openbmc/openbmc/wiki/Security-working-group>

- Joseph

Re: Security Working Group meeting - Wednesday October 13 - results

[Joseph Reynolds]

On 10/13/21 8:11 AM, Joseph Reynolds wrote:
> This is a reminder of the OpenBMC Security Working Group meeting 
> scheduled for this Wednesday October 13 at 10:00am PDT.
>
> We'll discuss the following items on the agenda 
> <https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI>, 
> and anything else that comes up:
>
> 1.
There were no topics when the meeting started.  We discussed 5 items:

Attended: Joseph Reynolds, Bruce Mitchell, Vernon Mauery, mbhavsar, 
Jiang Zhang, pravisash, James Mihm

1 CVE-2021-39296 is already publicly disclosed.  OpenBMC is ready to 
disclose.
Here are the existing public disclosures:
* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-39296 

* https://www.ibm.com/support/pages/node/6495437 

IBM PSIRT - https://www.ibm.com/trust/security-psirt
ASPEED Linux kernel patches are made regularly.
We discussed the desire to improve the OpenBMC Securty Response Team’s 
(SRT) coordinated disclosure.  Specifically, OpenBMC disclosed first, 
then whatever products which are built on OpenBMC disclosure the saem 
day and refers to the OpenBMC disclosure.

We agreed to publish advisories on 
https://github.com/openbmc/openbmc/security/advisories
TODO: Joseph to make this work, and look into creating the 
https://github.com/openbmc SRT team

2 Question about ipmi suite 3. This was removed: see notes 2020-04-29 below.
Existing ipmitool users can adapt in one of two ways: invoke ipmitool to 
use cipher suite 17 (`ipmitool -C 17 ...`) or use the latest ipmitool.
Was this change in the release notes?  Yes, here: 
https://github.com/openbmc/docs/blob/master/release/release-notes.md#security-audit-results-1 

The link to the latest ipmitool source is here: 
https://github.com/ipmitool/ipmitool/ sha 
7772254b62826b894ca629df8c597030a98f4f72 April 2018

3 We discussed “password over IPMI over DTLS” from before.
Email excerpt Oct 5, 2021 “SPAKE, DTLS and passwords + aPAKE and SCRAM”:

    Weakness of SRP (Secure Remote Password):
      - Server spoofing, there is nothing that prevents a server from
    being spoofed.
      - Widely adopted with very little proof of being cryptographically
    secure and has been shown vulnerable to pre-computation attacks

      - No feasible way to check for password complexity in the protocol
    (true for most aPAKE - asymmetric Password Authenticated Key Exchange)
      - Some debate over if actually provides forward secrecy.

    Recommendation to look at at OPAQUE aPAKE:
    https://blog.cloudflare.com/opaque-oblivious-passwords/

    Suggestion to use SCRAM
    https://en.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism



The SRP Server spoofing weakness is fully compensated for by the IPMI 
protocol which prevents spoofing, so is not an issue.  The other items 
apply.  We’ll continue to study this.

4 https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/39756 BMCWeb 
“Fix authorization rules” was mentioned in passing

5. USB control was continued from the previous meeting
Use case: UPS power supply plugged into USB port, uses RS-232 protocol.
Threat: Physically present attacker plugs in a USB device which says it 
is a UPS which lost power and will drop immediately so the BMC can do an 
orderly shutdown.  [Never mind that same attacker can just hit the power 
button.]
In this case, do we want to (1) ignore the signals from the UPS, or (2) 
read and log the signals but take no action.
In a hypothetical BMC systemd service to serve a UPS, if we wanted to 
disable it, would we (1) stop the service, or (2) reconfigure the 
service to continue to log signals but not take action.  Which approach 
is better?

BMC hardware SuperIO provides USB port capability.  Are there any other 
use cases within the OpenBMC community for BMC USB ports?  Is this an 
IBM-only use case?


>
>
>
> Access, agenda and notes are in the wiki:
> https://github.com/openbmc/openbmc/wiki/Security-working-group 
> <https://github.com/openbmc/openbmc/wiki/Security-working-group>
>
> - Joseph