ipmi password storage

[Joseph Reynolds]

On 4/14/20 5:44 PM, Vernon Mauery wrote:
> On 14-Apr-2020 05:18 PM, Joseph Reynolds wrote:
>> On 4/14/20 2:11 PM, Vernon Mauery wrote:
>>> On 14-Apr-2020 06:27 PM, Alexander Tereschenko wrote:
>>>> To be more specific, I'm considering two attack scenarios in the 
>>>> below comments:
>>>> 1) The attacker gets into BMC and is able to copy off the data 
>>>> files, including ipmi_pass. This IMHO is a more realistic scenario 
>>>> in this case.
>>>> 2) The attacker gets ipmi_pass file/contents only, without being 
>>>> able to retrieve anything else.
>>>>
>>>> Which ones do *you* have in mind? For the sake of discussion, it 
>>>> would be helpful to specify them all and see how potential 
>>>> solutions address them.
>>>
>>> Attack one is the most likely, since if you can read one file, you 
>>> can probably get any/all of them.
>>
>> An alternate solution is to make those file readable only by root, 
>> restricting root logins, and restricting SSH access in general.  See 
>> https://github.com/ibm-openbmc/dev/issues/1528
>
> Changes have been made already to restrict permissions to 0600. The 
> problem is that currently that is not much of protection at all 
> because all the processes run as root right now anyway.

Understood.  An attacker who gets control of any process will have read 
access to this file, etc.
The issue that all processes run as root is documented here 
https://github.com/openbmc/openbmc/issues/3383
and was recently discussed in the security working group, 2020-04-01 - 
https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI 


- Joseph

>
> --Vernon
>
>> In this way, only an admin can get the files by enabling the SSH 
>> interface, logging in via SSH, and using su or sudo to access the 
>> files.  All of these events should be audit-able.
>>
>> - Joseph
>>
>>>
>>>> On 14-Apr-20 01:00, Vernon Mauery wrote:
>>>>> Possible Solution
>>>>> =================
>>>>> Migrate to a solution that uses a key that is longer that does not 
>>>>> get written directly to the flash
>>>>> 1) S is now computed instead of hard-coded. S=HMAC(MachineId, AppID)
>>>>
>>>> I like the direction and the guiding principle, however from 
>>>> "proper" cryptography standpoint, for producing keys, this is not 
>>>> noticeably better than the previous solution. The key material is 
>>>> still readily available on the filesystem (making points #3 and #4 
>>>> irrelevant for attack scenario #1), so chances are that the 
>>>> adversary who can pull /etc/ipmi_pass file, can also pull 
>>>> /etc/machine-id one. In addition (but that's really a nitpick in 
>>>> this case with all these much bigger problems + easy to fix), plain 
>>>> HMAC is not a proper and recommended key derivation function, an 
>>>> HKDF or one of the NIST constructs from SP800-108 should be used 
>>>> instead.
>>>
>>> Cool. I did not know about HKDF. I will look into that.
>>>
>>>>> 2) S is longer (32 bytes instead of 8)
>>>> This (and #4) only helps the attack scenario #2, where attacker has 
>>>> to brute-force all possible values for S - and I believe that 
>>>> scenario is less realictic. But yes, case #2 gets a bit better than 
>>>> before, if we disregard the fact that HMAC is not a proper KDF and 
>>>> that MachineID is not a proper cryptographic key material [1, last 
>>>> paragraph in Description suggests that], which may provide 
>>>> additional advantage to the attacker. BTW, machine-id has at most 
>>>> 128 bits of entropy (if produced by a proper CSRNG, which I'm not 
>>>> sure about - e.g. I see they do some formatting), so practically 
>>>> it's not 32 bytes, but 16 [at most].
>>>
>>> Yes, this was mostly a minor point. And yes, the entropy in S is 
>>> limited by machine-id, but either one is better than a hard-coded 
>>> 8-byte ASCII string :)
>>>
>>>> So while this new approach does provide some advantage for scenario 
>>>> #2, it doesn't address a more important case of #1 and to me it 
>>>> still looks like low security. The proper way here is indeed to get 
>>>> some capability for storing the keys securely, but I see how this 
>>>> is hard to impossible on AST2500 (if that's what we're talking 
>>>> about here), without TrustZone or anything similar, or some sort of 
>>>> ROM/bootloader-accessible-only part-unique secret, so OTMH I can't 
>>>> propose any viable alternatives for a given context (brownfield 
>>>> deployment, backward compatibility), but I'll think more about that.
>>>>
>>>> [1] https://www.freedesktop.org/software/systemd/man/machine-id.html
>>>
>>> Really, I don't see a real solution without some kind of secure 
>>> storage, which we don't have at this time on the ast2500. While that 
>>> is not the only machine running OpenBMC, ideally the solution would 
>>> be platform independent so that any machine could do it. Maybe that 
>>> requirement would be that it supported some minimal cryptographic 
>>> features or something (like trustzone support). But in the meantime, 
>>> some sort of solution that security researchers will not rake us 
>>> over the coals for would be nice. Maybe there isn't one. Some 
>>> minimal configuration that is better than writing the passwords in 
>>> plain text.
>>>
>>> --Vernon
>>>
>>>
>>