CVEs in OpenWrt 22.03

[Dave Taht]

On Tue, Oct 25, 2022 at 7:37 AM Peter Naulls <peter at chocky.org> wrote:
>
> On 10/24/22 18:21, Hauke Mehrtens wrote:
>
> Hauke, thanks for replying!


As I said on a related thread - if an eu body can be found to care
more deeply on these issues, I'm pretty sure
30-50k of funding is available via one or more of nlnet's grant
programs. Applications for this round close december 1st.

https://nlnet.nl/

> >
> > 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.
>
> I'm afraid I don't have any explicit examples, but I'll let you know if
> find any.  There are some concerns with the older lua I mentioned below,
> but I'll need to come back to those. In any case, a suggestion for future
> CVE patches.
>
> >
> > 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/
>
> Yes, sure. And whether you or I agree with this or not is to some degree
> irrelevant, since what matters to the security people is that they see
> the bug fixed. In 90% of the cases I was able to dismiss CVEs
> since the subsystems in question are not in use by us (or most of OpenWrt
> for that matter. e.g, frame buffers), but some tricky ones remain.
>
> That said, there's a very large number of patches to the kernel in
> OpenWrt; mostly for new device function, pending fixes or whatnot;
> I guess few of these are actual security fixes.
>
> >> 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
>
> Yes, and was referred to and well understood by myself at least. Still, the
> objection is that Mitre have this as "disputed", which is rather unhelpful, and
> that is what is being focused upon. Obviously I cannot fix something that isn't
> broken and has no fix, so there's no satisfactory answer here to a security
> review beyond getting the CVEs dismissed from Mitre.
>
>
> >
> >> 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
>
> Sorry, trying to juggle lots of items here.
>
> https://nvd.nist.gov/vuln/detail/CVE-2018-16301
>
>
> >> Long since in OpenWrt patches.
> >>
> >> e2fsprogs 1.46.5 - CVE-2022-1304
> >
> > This is pretty hard to attack. You could provide a patch.
>
> This was the patch I provided here:
>
> >>
> >> I brought in this patch:
> >>
> >> diff --git a/lib/ext2fs/extent.c b/lib/ext2fs/extent.c
> >> index b324c7b0..1a206a16 100644
>
> Yes, very large files on OpenWrt are unlikely without external
> media.
>
> >>
> >> 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.
>
> Understood. I'm going to come back to this later in another post.
>
>
> >> 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.
>
> Yes, I know, and to say my reliance upon OpenWrt over the years is considerable
> would be an understatement, but my time is limited as well, and my focus
> must be on addressing specifics to the security review.  Still, I felt it
> better to at least have a partial discussion here, and do what little I can.
>
> I don't necessarily have time to roll patches in a format suitable
> for OpenWrt upstreaming; sometimes I think it's more constructive to simply
> point out what can be done, and have the maintainers do it. Maybe not ideal,
> but it's something.
>
> Look for some more posts on specific topics in the near future.
>
>
>
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel



-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
Dave Täht CEO, TekLibre, LLC