Re: [PATCH v2 0/7] 22.03 lantiq: add support for x490 Fritzboxes
On 10/23/22 13:19, Torsten Duwe wrote:
Hi all,
Here is my second attempt for initial FritzBox x490 support. 22.03 now
has all the necessary prerequisites, so support can be added according
to the rules.
The original code snippets were submitted by John Crispin (IIRC),
Andreas Böhler and Daniel Kestrel. I carved out the changes I
considered necessary, integrated and tested them and cleaned them up
(hopefully ;)
These are the minimal changes required to run the FB {3,7}490 as DSL
router (tested!). The 5490 is reported to be similar, so I included
it, but could not test it due to lack of hardware.
The wireless on these boxes is offloaded to a secondary SoC which
needs to be provided its own OS. This feature is explicitly left out
here in order to go step by step. I kept some loose ends where they
don't hurt, for future reference.
Changes from v1:
* return to squashfs for the rootfs; ubifs causes too much complexity
esp. for updates, when even the same model can be equipped with
varying flash chip geometries. UBI partitioning and volumes are kept
though.
Hi,
How is this related to the pull request adding support for these devices
on github?
https://github.com/openwrt/openwrt/pull/5075
The pull request on github looks mostly ok to me, I just had some minor
questions.
Hauke
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: how to add to list of Image files or supplementary files?
W dniu 20.10.2022 o 23:04, Tim Harvey pisze: > Greetings, > > How would I go about getting a file added to the list of Image Files > or Supplementary Files made by the auto-builder? > > For the octeontx target the kernel should be provided as a downloadable as > well. I'm not exactly sure, but the code installing images in octeontx target never gets called, because it lacks filesystem in FEATURES variable in target Makefile. This, in result, doesn't select any images by default. At least put "ramdisk" there, adding others might be also good, depending on boot medium. Check "Target Images" in menuconfig what's available. > > Best Regards, > > Tim Regards -- TMN ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: SBOM Tool for OpenWRT to feed Dependency Track
This work (cleaning up SBOM, clearly identifying CVEs, getting on top of more) sounds like an *ideal* candidate for funding under the NLNET entrust fund: https://nlnet.nl/entrust/ Applications are easy, the amount available per project usually in the range of 30-50k eu, and usually approval is very rapid. Go for it! tell me what you called the proposal and I'll put in a good word for you. Somewhat related, I've been looking for someones in europe (for a proposal to that fund) with xdp and ebpf experience to help both port libreqos.io (or bracketqos) to openwrt, and also harden it against not just DDOS attacks but malformed ecn usage. On Mon, Oct 24, 2022 at 3:38 PM Hauke Mehrtens wrote: > > On 10/18/22 16:38, Pfendtner Steffen wrote: > > Hi, > > > > We decided to publish our internal fork of the Timesys SBOM Tool we found on > > github. You find our version at: https://github.com/ads-tec/sbom-openwrt > > > > It takes a complete OpenWRT build tree as input and will generate a SBOM > > in CycloneDX JSON Format for the currently configured image. > > This SBOM can be fed into your personal dependency track instance. > > See https://dependencytrack.org/ if you don't know what this is. > > > > In my opinion Dependency Track is much more usable compared to uscan. > > > > However Dependency Tack currently heavily relies on valid CPE ID. Thus you > > will > > need to fix the CPE IDs in the OpenWRT package Makefiles - some are missing. > > I think it would be a great security benefit for the OpenWRT ecosystem if we > > get a best possible coverage of CPE IDs in the available Makefiles. > > > > I'll try to push our CPE ID additions upstream. > > > > Best regards, > > Steffen Pfendtner > > Hi Steffen, > > Nice tool, do you have some "demo" output for a recent OpenWrt release > somewhere? > > One advantage of uscan from my point of view is that I just have to open > a website to see the results for OpenWrt master and the maintained > branches and do not have to run some scripts and install some tooling > myself. > > Having multiple tools for such tasks is always helpful. Normally every > additional tool find additional problems. > > Adding the missing CPE IDs is no problem, someone just has to do it. If > you already have some internal changes with additional CPE IDs it would > be nice if you could send a patch or pull request adding them to OpenWrt > master and then we can backport it to OpenWrt 22.03 too. > > Petr added the missing CPE IDs to 4 packages recently. > > Hauke > > ___ > 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, TekLibre, LLC ___ 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: SBOM Tool for OpenWRT to feed Dependency Track
On 10/18/22 16:38, Pfendtner Steffen wrote: Hi, We decided to publish our internal fork of the Timesys SBOM Tool we found on github. You find our version at: https://github.com/ads-tec/sbom-openwrt It takes a complete OpenWRT build tree as input and will generate a SBOM in CycloneDX JSON Format for the currently configured image. This SBOM can be fed into your personal dependency track instance. See https://dependencytrack.org/ if you don't know what this is. In my opinion Dependency Track is much more usable compared to uscan. However Dependency Tack currently heavily relies on valid CPE ID. Thus you will need to fix the CPE IDs in the OpenWRT package Makefiles - some are missing. I think it would be a great security benefit for the OpenWRT ecosystem if we get a best possible coverage of CPE IDs in the available Makefiles. I'll try to push our CPE ID additions upstream. Best regards, Steffen Pfendtner Hi Steffen, Nice tool, do you have some "demo" output for a recent OpenWrt release somewhere? One advantage of uscan from my point of view is that I just have to open a website to see the results for OpenWrt master and the maintained branches and do not have to run some scripts and install some tooling myself. Having multiple tools for such tasks is always helpful. Normally every additional tool find additional problems. Adding the missing CPE IDs is no problem, someone just has to do it. If you already have some internal changes with additional CPE IDs it would be nice if you could send a patch or pull request adding them to OpenWrt master and then we can backport it to OpenWrt 22.03 too. Petr added the missing CPE IDs to 4 packages recently. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Removing writable permissions in squashfs images vs overlayfs
On 10/23/22 23:35, Phillip Lougher wrote: On Thu, Oct 20, 2022 at 6:01 PM Peter Naulls wrote: What you probably want is the following % mksquashfs test test.sqsh -action "chmod(ugo-w)@perm(/ugo+w)" It is, fantastic, thank you. I added to include/image.mk: --- a/include/image.mk +++ b/include/image.mk @@ -76,6 +76,7 @@ SQUASHFS_BLOCKSIZE := $(CONFIG_TARGET_SQUASHFS_BLOCK_SIZE)k SQUASHFSOPT := -b $(SQUASHFS_BLOCKSIZE) SQUASHFSOPT += -p '/dev d 755 0 0' -p '/dev/console c 600 0 0 5 1' SQUASHFSOPT += $(if $(CONFIG_SELINUX),-xattrs,-no-xattrs) +SQUASHFSOPT += -action 'chmod(ugo-w)@perm(/ugo+w)' SQUASHFSCOMP := gzip LZMA_XZ_OPTIONS := -Xpreset 9 -Xe -Xlc 0 -Xlp 2 -Xpb 2 ifeq ($(CONFIG_SQUASHFS_XZ),y) It sure seems like this could easily be an config option in OpenWrt, either allowing specific commands here, or some easy presets, or perhaps platform overrides. Again, I know this is theater and overlayfs rules here, but it's still important for my use. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
