Re: CVE-2018-3613 [was: MdeModulePkg Variable: Fix Timestamp zeroing issue on APPEND_WRITE]

[Laszlo Ersek <lersek@redhat.com>]

On 10/19/18 09:09, Zeng, Star wrote:
> Hi Laszlo,
> 
> Cc Qin also. Qin and Chao are secure boot experts, I also had some talk
> with them.
> 
> On 2018/10/19 5:45, Laszlo Ersek wrote:
>> Hi All,
>>
>> On 10/16/18 04:41, Star Zeng wrote:
>>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=415
>>>
>>> When SetVariable() to a time based auth variable with APPEND_WRITE
>>> attribute, and if the EFI_VARIABLE_AUTHENTICATION_2.TimeStamp in
>>> the input Data is earlier than current value, it will cause timestamp
>>> zeroing.
>>>
>>> This issue may bring time based auth variable downgrade problem.
>>> For example:
>>> A vendor released three certs at 2014, 2015, and 2016, and system
>>> integrated the 2016 cert. User can SetVariable() with 2015 cert and
>>> APPEND_WRITE attribute to cause timestamp zeroing first, then
>>> SetVariable() with 2014 cert to downgrade the cert.
>>>
>>> This patch fixes this issue.
>>>
>>> Cc: Jiewen Yao <jiewen.yao@intel.com>
>>> Cc: Chao Zhang <chao.b.zhang@intel.com>
>>> Cc: Jian J Wang <jian.j.wang@intel.com>
>>> Contributed-under: TianoCore Contribution Agreement 1.1
>>> Signed-off-by: Star Zeng <star.zeng@intel.com>
>>> ---
>>>   MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c | 2 ++
>>>   1 file changed, 2 insertions(+)
>>>
>>> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
>>> b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
>>> index a2d61c8cd618..8e8db71bd201 100644
>>> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
>>> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
>>> @@ -2462,6 +2462,8 @@ UpdateVariable (
>>>           if (Variable->CurrPtr != NULL) {
>>>             if (VariableCompareTimeStampInternal
>>> (&(((AUTHENTICATED_VARIABLE_HEADER *)
>>> CacheVariable->CurrPtr)->TimeStamp), TimeStamp)) {
>>>               CopyMem (&AuthVariable->TimeStamp, TimeStamp, sizeof
>>> (EFI_TIME));
>>> +          } else {
>>> +            CopyMem (&AuthVariable->TimeStamp,
>>> &(((AUTHENTICATED_VARIABLE_HEADER *)
>>> CacheVariable->CurrPtr)->TimeStamp), sizeof (EFI_TIME));
>>>             }
>>>           }
>>>         }
>>>
>>
>> I believe I found a significant mitigating factor for this
>> vulnerability.
> 
> Very good analysis, I totally agree. :)
> 
> Yes, if the dbx signature(includes the "attribute" information) was
> generated with "APPEND" attribute (that is the case you are seeing),
> it's infeasible to apply the downgrade write since the signature
> includes the "attribute" information, the PKCS7 verification will block
> the direct write without "APPEND" attribute.
> 
> But there may be some initial dbx signature was generated without
> "APPEND" attribute. E.g. OEM may have some this kind of dbx. It should
> be rarely case, but I am not sure about that.
> 
> Another, similar situation is also for other authenticated variables
> (not PK/KEK/DB/DBX/DBT).

Makes sense, thanks.

Laszlo