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
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
