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....@intel.com> >>> Cc: Chao Zhang <chao.b.zh...@intel.com> >>> Cc: Jian J Wang <jian.j.w...@intel.com> >>> Contributed-under: TianoCore Contribution Agreement 1.1 >>> Signed-off-by: Star Zeng <star.z...@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 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
