Re: CVEs in OpenWrt 22.03
On 10/25/22 17:21, Dave Taht wrote: On Tue, Oct 25, 2022 at 7:37 AM Peter Naulls 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: CVEs in OpenWrt 22.03
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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: CVEs in OpenWrt 22.03
On Tue, Oct 25, 2022 at 7:37 AM Peter Naulls 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 -- This song goes out to all the folk that thought Stadia would work: https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz Dave Täht CEO,
Re: CVEs in OpenWrt 22.03
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. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: CVEs in OpenWrt 22.03
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
Re: CVEs in OpenWrt 22.03
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? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
CVEs in OpenWrt 22.03
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. 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. 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. 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. busybox 1.35.0 - CVE-2022-30065 I brought in patches from here: https://bugs.busybox.net/show_bug.cgi?id=14781 tcpdump 4.9.3 - CVE-2018-16303 Long since in OpenWrt patches. e2fsprogs 1.46.5 - CVE-2022-1304 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? There's much more, but that's quite enough for now. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel