| Message ID | 86c923ab-58f0-89e6-9856-022d1cff21be@chocky.org |
|---|---|
| State | Not Applicable |
| Delegated to: | Petr Štetiar |
| Headers | show |
| Series | CVEs in OpenWrt 22.03 | expand |
I feel your pain, and with the dual provenance of the openwrt kernel (linux X.Y and usually a backport of mac80211) it gets harder. (But other world vendors have it much, much harder, with their frankenkernels) I don't know what guidelines are coming out of this effort (https://openssf.org/ ) is anyone in openwrt part of those processes?
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
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.
On Tue, Oct 25, 2022 at 7:37 AM Peter Naulls <peter@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@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
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
On 10/25/22 17:21, Dave Taht wrote: > On Tue, Oct 25, 2022 at 7:37 AM Peter Naulls <peter@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/ > Thanks for pointing it out. If someone wants to apply for this and improve the security of OpenWrt it would be nice. One problem is still the constant maintenance which is needed to keep it up to date. Hauke
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),