CVEs in OpenWrt 22.03

[Peter Naulls]

On 10/24/22 18:21, Hauke Mehrtens wrote:

Hauke, thanks for replying!

> 
> 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.