CVEs in OpenWrt 22.03

[Hauke Mehrtens]

On 10/25/22 16:29, Peter Naulls wrote:
> 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.

I do not care much about such security experts which are just able to 
hand a list of "problems" their broken tool found and now want fixes.

If you found a real problem patches are welcome, but best is probably to 
inform the stable Linux group.

Many security problems in the Linux kernel do not even get CVE numbers, 
relaying only on CVE numbers for the kernel is not reliable.

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

It would be good if someone could create a script finds all patches 
which have a Fixes tag referencing a patch we backported.

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

Hauke