Bug#988072: release.debian.org: unblick (pre-approval): hivex/1.3.20-1
Control: tags -1 moreinfo
On 2021-05-10 21:33:18, Salvatore Bonaccorso wrote:
> Hi Release Team,
>
> On Wed, May 05, 2021 at 12:37:20AM +0200, Hilko Bengen wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian.org@packages.debian.org
> > Usertags: unblock
> > X-Debbugs-Cc: none, Hilko Bengen <bengen@debian.org>
> >
> > Dear release team,
> >
> > I'd like to upload hivex to 1.3.20-1 to which fixes CVE-2021-3504 /
> > Debian bug #988024. Please unblock.
> >
> > The security fix consists of a patch to lib/handle.c and is described in
> > upstream git history:
> >
> > ,----
> > | commit 8f1935733b10d974a1a4176d38dd151ed98cf381
> > | Author: Richard W.M. Jones <rjones@redhat.com>
> > | Date: Thu Apr 15 15:50:13 2021 +0100
> > |
> > | lib/handle.c: Bounds check for block exceeding page length (CVE-2021-3504)
> > |
> > | Hives are encoded as fixed-sized pages containing smaller variable-
> > | length blocks:
> > |
> > | +-------------------+-------------------+-------------------+--
> > | | header |[ blk ][blk][ blk ]|[blk][blk][blk] |
> > | +-------------------+-------------------+-------------------+--
> > |
> > | Blocks should not straddle a page boundary. However because blocks
> > | contain a 32 bit length field it is possible to construct an invalid
> > | hive where the last block in a page overlaps either the next page or
> > | the end of the file:
> > |
> > | +-------------------+-------------------+
> > | | header |[ blk ][blk][ blk ..... ]
> > | +-------------------+-------------------+
> > |
> > | Hivex lacked a bounds check and would process the registry. Because
> > | the rest of the code assumes this situation can never happen it was
> > | possible to have a block containing some field (eg. a registry key
> > | name) which would extend beyond the end of the file. Hivex mmaps or
> > | mallocs the file, causing hivex to read memory beyond the end of the
> > | mapped region, resulting in reading other memory structures or a
> > | crash. (Writing beyond the end of the mapped region seems to be
> > | impossible because we always allocate a new page before writing.)
> > |
> > | This commit adds a check which rejects the malformed registry on
> > | hivex_open.
> > |
> > | Credit: Jeremy Galindo, Sr Security Engineer, Datto.com
> > | Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
> > | Fixes: CVE-2021-3504
> > | Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1949687
> > `----
> >
> > The debdiff (see attachments) is not minimal; apart from the security
> > fix there's only the following functional fix (lib/hivex-internal.h)):
> >
> > ,----
> > | commit 35ebe62bef0c801fab8956fd36a131ad497a5cea
> > | Author: Matt Coleman <matt@datto.com>
> > | Date: Thu Aug 13 15:48:16 2020 -0400
> > |
> > | Increase HIVEX_MAX_VALUES
> > |
> > | Due to unintended interaction between Windows and VMWare's snapshot
> > | functionality, HKLM\SYSTEM\MountedDevices can end up with more than
> > | 55,000 values.
> > `----
> >
> > The rest of the patch is made up of an update to the included gnulib
> > sources, localization updates, fuzzing instructions, and regenerated
> > Autotools build scripts.
> >
> > There are no changes to the Debian packageing.
>
> For buster DSA 4913-1 was released to fix this issue, so ideally this
> fix is present as well on bullseye. Does the debdiff look ok to you
> for inclusion based on rebasing to 1.3.20-1.
The bug report didn't make it to the list which is a good sign that the
debdiff is too big. Please provide a filtered debdiff without the
gnulib, auto*, etc. noise.
Cheers
--
Sebastian Ramacher
Reply to: