Commit Graph

13 Commits

Author SHA1 Message Date
Peter Jones
9bef30f529 sbat: Fix two NULL derefs found with "gcc -fanalyzer"
"gcc -fanalyzer" found two NULL pointer checks we're missing in sbat.c:

include/str.h: In function ‘get_sbat_field.part.0’:
sbat.c:20:14: error: dereference of NULL ‘offset’ [CWE-476] [-Werror=analyzer-null-dereference]
   20 |         if (!*offset)

and

include/str.h: In function ‘parse_sbat’:
sbat.c:140:27: error: dereference of NULL ‘current’ [CWE-476] [-Werror=analyzer-null-dereference]
  140 |         } while (entry && *current != '\0');

Both are simple, and this patch fixes them.

Signed-off-by: Peter Jones <pjones@redhat.com>
2021-02-19 14:28:10 -05:00
Javier Martinez Canillas
4c9654fb68 sbat: include NULL terminator when calculating buffer end in parse_sbat()
The parse_sbat() function is currently removing the last character of the
passed buffer, which will usually be a null-terminated string to parse.

There's no reason to do this and just take the whole size as specified by
the caller.

Reported-by: Chris Coulson <chris.coulson@canonical.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2021-02-19 14:28:10 -05:00
Javier Martinez Canillas
ea1c872418 Don't re-parse the SBAT EFI variable for each binary we load.
On a typical boot we validate at least two binaries; parsing the SBAT
EFI variable each time, when it should not be changing, is not worth the
effort.

This patch moves the parsing out to some setup code, instead of doing it
during the verification stage.

Signed-off-by: Peter Jones <pjones@redhat.com>
2021-02-19 14:28:10 -05:00
Peter Jones
1e78d701ac parse_sbat: handle the realloc failure leak and batch allocations.
Signed-off-by: Peter Jones <pjones@redhat.com>
2021-02-19 14:28:10 -05:00
Alex Burmashev
31e1aa7aca pe.c: parse SBAT variable and perform basic verification
Per Peter Jones suggestion, we will be flexible in what data we expect
while parsing the variable. Three fields are mandatory:
component_generation, component_name_size, component_name
However we also support adding comments and additional information to be
added after component name, with ',' as a separator. Those information
will be ignored and not used for verification purposes.
So:
grub,1
and
grub,1,wow,this,is,my,comment
will provide exactly same set of data for verification.

[0]: https://github.com/rhboot/shim/blob/main/SBAT.md

Signed-off-by: Alex Burmashev <alexander.burmashev@oracle.com>
Signed-off-by: Peter Jones <pjones@redhat.com>
2021-02-19 14:28:10 -05:00
Peter Jones
f1feb3ac04 sbat: drop the struct sbat and just use two variables instead
The struct sbat isn't doing anything and only has two fields so let's pass
pass those two to the functions directly instead of storing it in a struct.

Signed-off-by: Peter Jones <pjones@redhat.com>
2021-02-19 14:28:10 -05:00
Chris Co
a18d80ff98 sbat: add minor fixes to parse_sbat
Add parameter checking to parse_sbat().

Set end pointer to be sbat_base + sbat_size - 1. We directly
dereference the end pointer but this is technically outside of
our sbat_base buffer range.

Remove current and end while loops that account for extra CRLF
or LF characters before and after the .sbat section. We will
rely on automated tooling to verify the .sbat section is sane.

Remove the overwriting of *(end - 1) with '\0'. This behavior
causes a segfault in the unit test. parse_sbat_entry() expects
a very specific pattern "_,_,_,_,_,_\n" for every entry and uses
strchrnul() to process each individual field. When *(end - 1)='\0'
is present, it short-circuits the final \n and causes the final
get_sbat_field() to return NULL, thereby setting current = NULL.

Eventually parse_sbat attempts to access current in the do-while
condition and the segfault happens.

Signed-off-by: Chris Co <chrco@microsoft.com>
2021-02-16 16:42:27 +01:00
Javier Martinez Canillas
d1eb757feb sbat: remove unused buffer parameter in parse_sbat() function
It's a left over from an early implementation that was never cleaned.

Reported-by: Christopher Co <christopher.co@microsoft.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2021-02-16 16:42:27 +01:00
Peter Jones
0bc2aa4ca8 sbat: clang-format the whole thing.
Signed-off-by: Peter Jones <pjones@redhat.com>
2021-02-16 16:42:27 +01:00
Peter Jones
5fb5537fa9 sbat: make the includes work like everything else.
Signed-off-by: Peter Jones <pjones@redhat.com>
2021-02-15 18:40:07 +01:00
Javier Martinez Canillas
ee8f7ed332 Add a function to parse the SBAT metadata from the .sbat section
Parse the SBAT [0] Version-Based Revocation Metadata that's contained in a
.sbat data section of the loaded PE binary. This information is used along
with data in a SBAT variable to determine if a EFI binary has been revoked.

[0]: https://github.com/rhboot/shim/blob/sbat/SBAT.md

Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2021-02-13 11:02:59 -05:00
Peter Jones
16732ad128 Add the beginning of .sbat parsing stuff
Signed-off-by: Peter Jones <pjones@redhat.com>
2021-02-13 11:02:59 -05:00
Javier Martinez Canillas
6d13718c80 Add a .sbat section to EFI binaries
The Secure Boot Advanced Targeting (SBAT) [0] is a Generation Number Based
Revocation mechanism that is meant to replace the DBX revocation file list.

Binaries must contain a .sbat data section that has a set entries, each of
them consisting of UTF-8 strings as comma separated values. Allow to embed
this information into the fwupd EFI binary at build time.

The SBAT metadata must contain at least two entries. One that defines the
SBAT version used and another one that defines the component generation.

This patch adds a sbat.csv that contains these two entries and downstream
users can override if additional entries are needed due changes that make
them diverge from upstream code and potentially add other vulnerabilities.

The same SBAT metadata is added to the fallback and MOK manager binaries
because these are built from the same shim source. These need to have SBAT
metadata as well to be booted if a .sbat section is mandatory.

[0]: https://github.com/rhboot/shim/blob/sbat/SBAT.md

Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2021-02-12 12:51:32 -05:00