CVEs in OpenWrt 22.03

[Hauke Mehrtens]

On 10/20/22 22:26, Peter Naulls wrote:
> 
> Apologies for the obtuseness of the previous email about the squashfs 
> permissions - that's related to the following, but a different topic.  I 
> can now
> say that we're undergoing a security review for our system which is very 
> much
> based upon OpenWrt 22.03.
> 
> If you have ever done this, you'll probably know what's in such things, 
> lots
> of picky items, much that is to be polite, spurious and many other things
> which are of little relevance, but are security theater and therefore
> important to people who make such reports.  Nevertheless, I do have to
> provide answers and "proof" for everything.
> 
> The following is partly for my own benefit, but it might benefit anyone
> else who is settling upon 22.03 for a stable version and will be doing
> the same in the near future.
> 
> First a request on patch naming in OpenWrt - if it's a specific CVE 
> patch, then
> it would help that it was named that. I know that often isn't possible, 
> since
> often they get rolled up into other upstream patches, pulled out of git, 
> etc, etc, but it would help.

I also prefer if the CVE number is named in the patch. If this is 
missing somewhere you could send a patch or pull request to rename the 
patch.

> For the kernel, a great many of the CVEs in my report relate to the 5.15
> kernel series. The dumb assumption here is a that the 5.10 series
> kernel is "older", and therefore these must apply to. The reality is that
> in most cases, these are issues introduced in that series for new features,
> or they've been backported by either the 5.10 maintainers or the OpenWrt
> maintainers, both of who I know are on top of such things.
> 
> For other remaining CVEs, sometimes it's very hard to know, unless you
> can (a) rule out for sure the driver/subsystem isn't in use, or failing
> that (b) close code examination and hand-waving that the patch isn't
> relevant, sans intimate knowledge of the codebase.
> 
> CVE-2022-500 and CVE-2021-4150 are examples here.
> 
> For CVE-2022-39188, CVE-2021-3669, it seems like they might get 5.10 series
> patches, if they are relevant, so I will wait on a kernel bump on those.

The OpenWrt project does not have enough resources to maintain security 
patches for the kernel on our own. OpenWrt relays on the LTS kernel 
maintenance and we update to the most recent LTS version every few days 
or weeks in the maintained branches. If some security patches are 
missing in the LTS kernel versions used by OpenWrt it is probably best 
to approach the Linux stable team directly.

See this blog post from Greg Kroah-Hartman, especially the "Keeping a 
secure system" section:
http://kroah.com/log/blog/2018/02/05/linux-kernel-release-model/

> So, to user space:
> 
> dnsmasq 2.86 - my pointing out that CVE-2021-45957 et al are false 
> didn't go
> over particularly well, even though they have been properly dismissed by
> the Simon Kelley and others.

See my mail on the dnsmasq mailing list:
https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2022q1/016161.html

> However, there is CVE-20220-0934.
> 
> https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=03345ecefeb0d82e3c3a4c28f27c3554f0611b39
> 
> Which can easily be patched, or update to dnsmasq 2.87.

Thank you, I was not aware of this problem.

> busybox 1.35.0 - CVE-2022-30065
> 
> I brought in patches from here:
> 
> https://bugs.busybox.net/show_bug.cgi?id=14781

Someone should backport these changes.

> 
> tcpdump 4.9.3 - CVE-2018-16303

This CVE is not for tcpdump, but PDF-XChange Editor:
https://nvd.nist.gov/vuln/detail/CVE-2018-16303

> 
> Long since in OpenWrt patches.
> 
> e2fsprogs 1.46.5 - CVE-2022-1304

This is pretty hard to attack. You could provide a patch.

> 
> I brought in this patch:
> 
> diff --git a/lib/ext2fs/extent.c b/lib/ext2fs/extent.c
> index b324c7b0..1a206a16 100644
> --- a/lib/ext2fs/extent.c
> +++ b/lib/ext2fs/extent.c
> @@ -495,6 +495,10 @@ retry:
>               ext2fs_le16_to_cpu(eh->eh_entries);
>           newpath->max_entries = ext2fs_le16_to_cpu(eh->eh_max);
> 
> +        /* Make sure there is at least one extent present */
> +        if (newpath->left <= 0)
> +            return EXT2_ET_EXTENT_NO_DOWN;
> +
>           if (path->left > 0) {
>               ix++;
>               newpath->end_blk = ext2fs_le32_to_cpu(ix->ei_block);
> @@ -1630,6 +1634,10 @@ errcode_t 
> ext2fs_extent_delete(ext2_extent_handle_t handle, int flags)
> 
>       cp = path->curr;
> 
> +    /* Sanity check before memmove() */
> +    if (path->left < 0)
> +        return EXT2_ET_EXTENT_LEAF_BAD;
> +
>       if (path->left) {
>           memmove(cp, cp + sizeof(struct ext3_extent_idx),
>               path->left * sizeof(struct ext3_extent_idx));
> 
> 
> lua 5.1.5 and lua 5.3.
> 
> CVE-2014-5461 and others. lua 5.1.5 has been heavily patched in OpenWrt,
> and I suspect these have all long since been fixed.
> 
> If would be simply easier on the optics if I was able to ditch 5.1.5 in the
> build and just use 5.3 - is this possible; I'm sure there's been much
> discussion on this before, so please point me at that - will it break luci?

An update to Lua 5.4 would be good, but I do not know which impact it has.

> 
> There's much more, but that's quite enough for now.

OpenWrt is a mostly volunteer run project. Especially (security) 
maintenance does not get paid by companies. If you have some fixes 
tested patches would be really helpful.

Hauke