Re: [OE-core][mickledore 02/26] dmidecode: fix CVE-2023-30630

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Tue, 2023-07-18 at 17:48 -0400, Randy MacLeod via lists.openembedded.org wrote:
> 
> Add Kai,
> 
> On 2023-07-14 18:32, Steve Sakoman via lists.openembedded.org wrote:
>  From: Yogita Urade <yogita.urade@windriver.com>
> > 
> > Dmidecode before 3.5 allows -dump-bin to overwrite a local file.
> > This has security relevance because, for example, execution of
> > Dmidecode via Sudo is plausible.
> > 
> > References:
> > https://nvd.nist.gov/vuln/detail/CVE-2023-30630
> > https://lists.nongnu.org/archive/html/dmidecode-devel/2023-04/msg00016.html
> > https://lists.nongnu.org/archive/html/dmidecode-devel/2023-04/msg00017.html
> > 
> > Signed-off-by: Yogita Urade <yogita.urade@windriver.com>
> > Signed-off-by: Steve Sakoman <steve@sakoman.com>
> > ---
> >  .../dmidecode/CVE-2023-30630_1.patch          | 237
> > ++++++++++++++++++
> >  .../dmidecode/CVE-2023-30630_2.patch          |  81 ++++++
> >  .../dmidecode/CVE-2023-30630_3.patch          |  69 +++++
> >  .../dmidecode/CVE-2023-30630_4.patch          | 137 ++++++++++
> >  
> 
> Summary:
>  
>     I think this can merge but we should agree on how to handle
> dmidecode.
>  
> Details:
>  
> These changes work but it's bringing back 4 patches rather than
> bumping the version to 3.5
>  and picking up 2 patches. My conclusion is that it's okay but we
> should probably talk
>  about how to maintain dmidecode since it just produces a bunch of
> programs for dumping
>  HW DMI/SMBIOS info and doesn't provide a runtime ABI, we can
> probably update to 3.5 
>  ( or even 3.6 when that's out).
>  
> Do you agree Steve?
>  
>  
> The patches back-ported are:
>  
> ❯ rg -i "subject: \[PATCH\]" /tmp/dmidecode-mickledore-cve.eml 
>  201:+Subject: [PATCH] dmidecode: Write the whole dump file at once
>  444:+Subject: [PATCH] dmidecode: Do not let --dump-bin overwrite an
> existing file
>  531:+Subject: [PATCH] Consistently use read_file() when reading from
> a dump file
>  606:+Subject: [PATCH] Don't read beyond sysfs entry point buffer
>    
> Two of these patches would be picked up if we update mickledore to
> 3.5 - so let's look at what changed:
>  
> ❯ git log --oneline dmidecode-3-4..dmidecode-3-5
>  
> 484f893 (tag: dmidecode-3-5) Set the version to 3.5
>  8baf2f5 Fix a build warning when USE_MMAP isn't set
>  b9ebecc dmioem: HPE type 242: Fix ID on 32-bit systems
>  189ca35 Ensure /dev/mem is a character device file
>  8427888 dmidecode: Use the right variable for -s bios-
> revision/firmware-revision
>  6ca381c dmidecode: Do not let --dump-bin overwrite an existing file
> <---------- Added.
>  d8cfbc8 dmidecode: Write the whole dump file at
> once                       <---------- Added.
>  39b2dd7 dmidecode: Split table fetching from decoding
>  11b168f dmioem: Avoid intermediate buffer (HPE type 216)
>  9d2bbd5 dmioem: Decode HPE OEM Record 216
>  3d68350 dmidecode: Drop the CPUID exception list
>  c1a2520 dmidecode: Add a --no-quirks option
>  67dc0b2 dmidecode: Fortify entry point length checks
>  f801673 dmioem: Typo fix (Virutal -> Virtual)
>  90d1323 dmioem: Decode HPE OEM Record 242
>  f50b925 dmioem: Update HPE OEM Record 238
>  ac24b67 dmioem: Decode HPE OEM Record 230
>  c3357b5 dmioem: Fix segmentation fault in dmi_hp_240_attr()
>  a1a2258 dmioem: Decode HPE OEM Record 224
>  fb8766a NEWS: Fix typo
>  
>  My summary of the changes above: 
>   - support additional HW,
>  
>  -  fix bugs, typos and build warnings.
>  
>  - internal program restructuring: 39b2dd7 dmidecode: Split table
> fetching from decoding
>  
> I was a bit concerned about:
>  
>  
>    3d68350 dmidecode: Drop the CPUID exception list
>  
> but it's pretty arcane (1) and only affects HW from 2008 or earlier
>  
> so we should be okay with that change!

This discussion seems like it is starting to appear on a number of
recipes each time we have to backport CVE fixes.

The policy is very clear for good reasons. We do not take upgrades
where there are mixes of features and fixes. We only take upgrades
where they are part of some kind of stable series that the upstream is
promoting/supporting.

The policy is like this to make things clear cut. Yes, there are fuzzy
cases where you can make the argument but that is not the policy.

You can make this argument for many different pieces of software and I
don't want to see this discussion happening every time. I really don't
want to keep seeing this discussion coming back up either. There is
risk starting to make guesses about what feature changes do and these
are not the risks we've stated the stable series supports.

If someone wants to maintain a branch where they upgrade all the
software to the latest versions they can feel free to do so but it will
look a lot like master.

Cheers,

Richard