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

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

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).

Thanks!
Laszlo