Re: [edk2-devel] [PATCH v2 0/8] support server identity validation in HTTPS Boot (CVE-2019-14553)

["Laszlo Ersek" <lersek@redhat.com>]

On 10/31/19 10:28, Laszlo Ersek wrote:
> On 10/26/19 07:37, Laszlo Ersek wrote:
>> Repo:   https://github.com/lersek/edk2.git
>> Branch: bz960_with_inet_pton_v2
>> Ref:    https://bugzilla.tianocore.org/show_bug.cgi?id=960
> 
>> In v2, I have inserted 4 new patches in the middle, to satisfy two
>> additional requirements raised by Siva and David:
>>
>> - If the Subject Alternative Name in the server certificate contains an
>>   IP address in binary representation, and the URL specifies an IP
>>   address in literal form for "hostname", then both of those things
>>   should be compared against each other, after converting the literal
>>   from the URL to binary representation. In other words, a server
>>   certificate with an IP address SAN should be recognized.
>>
>> - If the URL specifies an IP address literal, then, according to
>>   RFC-2818, "the iPAddress subjectAltName must be present in the
>>   certificate and must exactly match the IP in the URI". In other words,
>>   if a certificate matches the IP address literal from the URL via
>>   Common Name only, then the certificate must be rejected.
>>
>> I've also fixed two commit message warts in Jiaxin's patches (see the
>> Notes sections on the patches).
>>
>> I've tested the series painstakingly. [...]
> 
>> And here's the test matrix:
>>
>>> Server Certificate     URL                   cURL              edk2 unpatched    edk2 patched
>>> ---------------------  --------------------  ----------------  ----------------  ----------------
>>> Common      Subject    hostname    resolves  status  expected  status  expected  status  expected
>>> Name        Alt. Name              to IPvX
>>> -------------------------------------------------------------------------------------------------
>>> IP-literal  -          IP-literal  IPv4      accept  COMPAT/1  accept  NO/2      reject  yes
>>> IP-literal  -          IP-literal  IPv6      accept  COMPAT/1  accept  NO/2      reject  yes
>>> IP-literal  -          domainname  IPv4      reject  yes       accept  NO/2      reject  yes
>>> IP-literal  -          domainname  IPv6      reject  yes       accept  NO/2      reject  yes
>>> IP-literal  IP         IP-literal  IPv4      accept  yes       accept  yes       accept  yes
>>> IP-literal  IP         IP-literal  IPv6      accept  yes       accept  yes       accept  yes
>>> IP-literal  IP         domainname  IPv4      reject  yes       accept  NO/2      reject  yes
>>> IP-literal  IP         domainname  IPv6      reject  yes       accept  NO/2      reject  yes
>>> domainname  -          IP-literal  IPv4      reject  yes       accept  NO/2      reject  yes
>>> domainname  -          IP-literal  IPv6      reject  yes       accept  NO/2      reject  yes
>>> domainname  -          domainname  IPv4      accept  yes       accept  yes       accept  yes
>>> domainname  -          domainname  IPv6      accept  yes       accept  yes       accept  yes
>>> domainname  IP         IP-literal  IPv4      accept  yes       accept  yes       accept  yes
>>> domainname  IP         IP-literal  IPv6      accept  yes       accept  yes       accept  yes
>>> domainname  IP         domainname  IPv4      accept  yes       accept  yes       accept  yes
>>> domainname  IP         domainname  IPv6      accept  yes       accept  yes       accept  yes
>>>
>>> #1 -- should not be accepted: an IP literal in the URL must match the IP
>>> address in the SAN, regardless of the Common Name; but cURL accepts it
>>> for compatibility
>>>
>>> #2 -- this is (or exemplifies) CVE-2019-14553
> 
> Based on the feedback thus far, I'm planning to push this set on
> Saturday (that is, after 1 week of list-time), or perhaps next Monday
> (depends on how my Saturday will look).


Pushed as commit range b15646484eaf..e2fc50812895.

Thanks,
Laszlo