Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Next revisionBoth sides next revision
docs:guide-developer:security [2019/09/25 07:57] pepesdocs:guide-developer:security [2023/10/13 09:25] – add 23.05 hauke
Line 1: Line 1:
 ====== Security ====== ====== Security ======
-===== Security Advisories & Vulnerability Reporting =====+See [[:docs/guide-developer/security/old|Security old]] for the old page.
  
-Security bugs seem to not be treated differently than other kinds of bugs, so one should probably follow the normal bug reporting procedures documented in the [[:bugs]] wiki pageOn the other hand, the mailing list thread [[https://lists.openwrt.org/pipermail/openwrt-devel/2015-March/032169.html|[OpenWrt-Devel] Security Vulnerability Reporting and Database]] indicated that security vulnerabilities be reported by sending an email to the public  +This page lists the processes, tools and mechanisms OpenWrt uses to the security of OpenWrt. 
-[[https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel|openwrt-devel]] mailing list. Whichever way it is doneit is better to report a vulnerability than not report it.+This covers the OpenWrt distribution with the official package feeds hosted at https://github.com/openwrt/ and also the OpenWrt specific tools hosted at https://git.openwrt.org/ like procdubus and libubox
  
-Vulnerabilities in third-party components of OpenWrt, like the Linux kernel, OpenSSL, etc. should be reported directly to the third-party project first unless the vulnerability is somehow OpenWrt-specific (e.g. the vulnerability is in a OpenWrt patch to the third-party component).+===== Vulnerability reporting ===== 
 +Security bugs should be reported in confidentiality to [[contact@openwrt.org]], see [[:bugs#reporting_security_bugs|Reporting security bugs]] for details.
  
-  * FIXME: Much of this information is useful for users as well as developers, so the non-developer-specific information should be moved to a more general page, with a link to that page here.+===== Security advisories =====
  
-===== Threat Model =====+/** Omit the footer because the edit/create date is inaccurate because the page's contents are autogenerated. */ 
 +{{page>advisory:start&link&nofooter}}
  
-  * FIXME: Adapt [[https://github.com/EFForg/OpenWireless/blob/master/security.txt|OpenWireless's threat model documentation]] to OpenWrt.+This only lists security advisories for components maintained directly by the OpenWrt team. This does not list all fixed security problems in third party components used by OpenWrt which can also affect the security of OpenWrt. We do not list known security problems in the Linux kernel, openssl and other third party components even when they affect use cases relevant for OpenWrt. The OpenWrt team monitors the upstream projects and backports security fixes for components used in the OpenWrt core repository to still supported OpenWrt versions. For example  [[https://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33|159 CVEs]] were assigned to the Linux kernel in 2021 alone, OpenWrt regularly updates the minor Linux kernel version to get the recent fixes.
  
-===== Security Updates =====+===== Support status ===== 
 +This lists the currently support or not supported OpenWrt versions.
  
-Most people set up their device once and then don't touch it, as long as it appears to be workingIn particular, very few people make a habit of checking for updates.+^ Version ^ Current status ^ Projected EoL ^ 
 +| 23.05 | Fully supported | - | 
 +| 22.03 | Security maintenance | EoL (April 2024) | 
 +| 21.02 | End of life | EoL (May 2023) | 
 +| 19.07 | End of life | EoL (April 2022) | 
 +| 18.06 | End of life | EoL | 
 +| 17.01 | End of life | EoL | 
 +| 15.05 | End of life | EoL |
  
-  * FIXME: How can updates be made automatic and enabled by default? +The projected EoL can be extended laterdepending on the future situation, like the release date of the next release.
-  * FIXME: How can automatic updates be done in a non-disruptive wayas Google claims for OnHub? +
-  * FIXME: OpenWrt supports many routers that come with stock firmware that supports automatic updates. Are any of them based on OpenWrt? Could OpenWrt base an automatic update mechanism on one? +
-  * FIXME: How can we ensure that updates are failsafe and can be easily rolled back or aborted? +
-  * FIXME: Does the squashfs+JFFS2 overlay system and the opkg package manager make sense with respect to automatic updates? In particularif updates are done by writing to the JFFS2 filesystem then the system could easily run out of space over time as the JFFS2 diffs from the squashfs filesystem accumulate. Also, usually OpenWrt firmware is quite small, so it may not be worth trying to do partial system updates when full updates are probably good enough. But then, can we afford to store both the old and new versions of the firmware at the same time? Regardless of all of that, it still may be useful to separate updates of the bootloader and kernel from other updates, because the latter are likely to be more disruptive than the former. +
-  * FIXME: Automatic updates rely on cryptographic signatures of the updates to ensure that the updates are from a trusted source; i.e. are not malicious. But, in a decentralized project like OpenWrt, there's no one person that can be trusted with the signing keys. And, also, there are so many different configurations of OpenWrt for various kinds of hardware and user preferences that it would be impossible for one person or organization to properly QA all the updates. Perhaps some kind of voting system for trustworthiness of updates; such a system would almost definitely depend on reproducible builds.+
  
-Background:+The Version references the most recent stable version from this release branch.
  
-  * [[docs:guide-user:installation:generic.sysupgrade]] discusses how updates work. +  * Fully supported means that the OpenWrt team provides updates for the core packages fixing security and other problems we are aware of
-  * Turris OS is based on top of OpenWrt and has automatic updates. See https://www.turris.cz/en/software for the claim and see https://gitlab.labs.nic.cz/turris/updater for the code+  * Security maintenance means that the OpenWrt team fixes only security problems in this release but no bugs any more
-  * Google's "OnHub automatically updates with new features and the latest security upgrades, without interrupting your connection." (OnHub is [[https://blog.exploitee.rs/2015/gaining-root-on-the-google-onhub/|based on Chromium OS]], which in turn is [[https://www.zdnet.com/article/the-secret-origins-of-googles-chrome-os/|based on Gentoo Linux's Portage System]]). See https://www.chromium.org/chromium-os/chromiumos-design-docs/filesystem-autoupdate and https://www.chromium.org/chromium-os/chromiumos-design-docs/filesystem-autoupdate-supplements+  * End of life means that we will *notprovide any updates also for severe security problemPlease update to more recent versions.
-  * FirefoxOS was based on Android and reuses Android's update mechanisms for the Linux stuff. However, it also had some features for less disruptive automatic updates of userspace parts that may be worth looking at.  +
-  Android itself has a well-studied update mechanism, though it isn't automatic. +
-  Freifunk's remote-update tool is in the [[https://github.com/openwrt/luci/blob/for-15.05/contrib/package/remote-update/files/usr/sbin/remote-update|LuCI repo]].+
  
-===== Reproducible Builds =====+A OpenWrt major version will get into fully supported status after it was initially released. 
 +When the next OpenWrt major version is released the old version will move into security maintenance mode. 
 +A OpenWrt major version will move into end of Life 1 year after the initial release or 6 months after the release of the next major versions. The later date will be used. We plan to do a final minor release at the end of the support cycle.
  
-FIXME: Write this section.+This only covers the core OpenWrt packages and not the external package feeds hosted on github. 
 +Some feed package maintainer do not take care of all OpenWrt versions where the the core components are still supported. 
 +For the best security support we suggest everyone to upgrade to the most recent stable version.
  
-Background info:+===== Identifying problems ===== 
 +The OpenWrt project uses multiple tools to identify potential security problems. 
 +The information are normally available for everyone and we appreciate fixes for problems reported by these tools form everyone.
  
-  * Motivation (not specific to OpenWrt): [[https://reproducible-builds.org/]] and [[https://wiki.debian.org/ReproducibleBuilds/About]] +==== uscan ==== 
-  [[https://lists.openwrt.org/pipermail/openwrt-devel/2015-March/032140.html]] +The [[https://sdwalker.github.io/uscan/index.html|uscan report]] shows the version number of all packages from the base and the package repository and compares it against the recent upstream released versions. 
-  * HOWTO (not OpenWrt-specific): [[https://reproducible-builds.org/docs/]] +In addition the tool which generates this page also checks for existing CVEs assigned to the packages based on the Common Platform Enumeration (CPEwhich is listed in the PKG_CPE_ID variable of many packages
-  * OpenWrt specifics: [[https://reproducible.debian.net/openwrt/openwrt.html]]+That page is updated weekly for master and the active release branches.
  
-===== Binary-Blob-free Builds =====+==== Coverity Scan ==== 
 +OpenWrt uses the commercial [[https://scan.coverity.com/projects/openwrt|Coverity Scan]] tool which is available for free to open source projects to do static code analyses on the OpenWrt components. 
 +This scans one OpenWrt build per week and reports the problems found in the components developed in the OpenWrt project like procd and ubus, but not on (patched) third party components.
  
-Many people are interested in OpenWrt because they believe that it being open source improves security because the code has been (in theory) been carefully reviewedFurther, one of the goals of having reproducible builds is to ensure that the binaries downloaded and installed onto a device derived from the carefully-reviewed OpenWrt source codeObviously, the OpenWrt doesn't have access to the source code for binary blobs and so it can't review them, and so binary blobs are counterproductive to security. Yet some hardware doesn't work as well, or at all, without the binary blobs, and some users don't care about this issue.+===== Reproducible builds ===== 
 +The [[https://reproducible.debian.net/openwrt/openwrt.html|reproducible builds project]] checks that OpenWrt master is still reproducible. 
 +This proves that the produced releases really match the delivered source code and no backdoors were introduced in the build process.
  
-  * FIXME: What can be done to help developers configure a 100%-binary-blob-free build? +===== Deliver to users ===== 
-  * FIXMEWhat can be done to document which binary blobs, if any, are used by a particular build? +OpenWrt operates multiple [[:infrastructure#Buildbot|build bot instances]] which are building snapshots of the ''master'' and the supported release branches.
-  * FIXME: What can be done to facilitate better sharing between LibreCMC and OpenWrt? The OpenWrt trunk has more hardening options, has better defaults for security-related build options, and has support for more devices, but it isn't clear if/when/what closed-source components are included in the build. LibreCMC has already done a lot of great work to get good results without closed-source components, but it has limited device support; in particular, there seem to be devices that aren't "supported" by LibreCMC but which do--or can be easily made to--work without binary blobs.+
  
-Background:+When a change to a package is committed to the OpenWrt base repository of package feed, the build bots are automatically detecting this change and will rebuild this package. 
 +The newly built package can then be installed with opkg or be integrated with the image builder by users of OpenWrt. 
 +This allows us to ship updates in about 2 days to the end users.
  
-  * [[https://lists.openwrt.org/pipermail/openwrt-devel/2010-July/007556.html]] - Reading the whole thread is recommended, as options for creating "blob free" builds in OpenWrt without a fork are discussed+The kernel is normally located in its own partition and upgrades are not so easily possible
-  * [[https://librecmc.org/]] - A binary-blob-free OpenWrt fork. LibreWRT and CeroWrt merged into LibreCMC.+Therefore this mechanism currently does not work for the kernel itself and kernel modules and a new minor release is needed to ship fixes to end users.
  
-===== General Concerns to Address ===== +===== Hardening build options ===== 
- +OpenWrt activates some build hardening options in the [[https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=config/Config-build.in|build configuration]] at compile time for all package builds. 
-  * FIXME: See [[https://lwn.net/Articles/649870/]]. OpenWrt has many private patches to the kernel and other packages that are applied using the quilt tool. These patches have likely not been as well-reviewed as patches that have been accepted in upstream patches. How can we get all of OpenWrt's packages reviewed & accepted upstream? How can one get a list of all of OpenWrt's patches? +Note that individual packages and/or targets may ignore or otherwise not respect these settings.
-  * FIXME: Besides private patches, OpenWrt does many things differently than other Linux distros. Many of these things are done to make OpenWrt fit on the very small devices that it typically runs on. What, exactly, are these differences? How can we audit +
-  * FIXME: "Everything runs as root." See [[https://forum.openwrt.org/viewtopic.php?pid=287257#p287257]] and [[https://lists.openwrt.org/pipermail/openwrt-devel/2015-March/032197.html]]. Right now it is difficult to tell what even needs to be done. +
-  * FIXME: [[http://blog.oldcomputerjunk.net/tag/openwrt/|"OpenWrt is using 2 year old release of uClibc [...]"]]. Now OpenWrt is using musl libc instead of uClibc to address this. but it is using uClibc++; does uClibc++ have the same maintenance issues as uClibc?  +
-  * FIXME: [[http://blog.oldcomputerjunk.net/tag/openwrt/|"[...] and 1 year old release of binutils, etc."]]. How is OpenWrt doing in keeping up-to-date with packages and toolchains? +
-  * [[https://github.com/EFForg/OpenWireless/issues]] has some good ideas that haven't been implemented yet. +
- +
-===== OS and Package Hardening ===== +
- +
-See the configuration files under [[https://github.com/openwrt/openwrt/tree/master/config| config/]] in the source tree for more detailed information about each option, such as the label used in "make menuconfig", the current default value, and prerequisites and conditions for enabling the feature. In particular, "Yes" in the "Enabled by Default" column is often an oversimplification. Options are listed in the order they are listed in their config/Config-*.in file. +
- +
-==== Using ''checksec'' to Check Your Build ==== +
- +
-''checksec'' can be used to verify that some executables and/or libraries have been correctly built with many of these options. To use it: +
- +
-  - ''git clone https://github.com/slimm609/checksec.sh'', somewhere outside your OpenWrt tree. +
-  - Build OpenWrt with ''CONFIG_TARGET_ROOTFS_TARGZ=y'' so that it generates a tar.gz archive. +
-  - Extract the .tar.gz archive to a temporary directory. +
-  - Run the ''checksec'' script from inside your copy of the repo you cloned in the first step. +
- +
-Note that a lot of documentation for this tool--including the README.md in its GitHub repo--suggests running it as ''checksec.sh'' but the script was renamed to ''checksec''. See [[http://blog.oldcomputerjunk.net/2014/evaluating-the-security-of-openwrt-part-2/|Evaluating the security of OpenWrt (part 2)]] for help on analyzing the outputOpenWrt has improved since that blog post was written so your results should be better. +
- +
-==== "Hardening build options" in config/Config-build.in === +
- +
-Source: [[https://github.com/openwrt/openwrt/blob/master/config/Config-build.in|config/Config-build.in]]. Note that individual packages and/or targets may ignore or otherwise not respect the setting. +
- +
-^ .config line ^ Enabled by Default? ^ Notes ^ +
-| ''CONFIG_PKG_CHECK_FORMAT_SECURITY=y'' | Yes | ''-Wformat -Werror=format-security''+
-| ''CONFIG_PKG_CC_STACKPROTECTOR_STRONG=y'' | | "Regular" is the default. "Strong" requires GCC 5. | +
-| ''CONFIG_KERNEL_CC_STACKPROTECTOR_STRONG=y'' | | "Regular" is the default. "Strong" requires GCC 5. | +
-| ''CONFIG_PKG_FORTIFY_SOURCE_2=y'' | | ''CONFIG_PKG_FORTIFY_SOURCE_1=y'' is the default. | +
-| ''CONFIG_PKG_RELRO_FULL=y'' | Yes | | +
- +
-==== More Security-related Kernel Build Options in config/Config-kernel.in ==== +
- +
-Source: [[https://github.com/openwrt/openwrt/blob/master/config/Config-kernel.in|config/Config-kernel.in]] +
- +
-^ .config line ^ Enabled by Default? ^ Notes ^ +
-| ''CONFIG_KERNEL_SECCOMP_FILTER=y''\\ ''CONFIG_KERNEL_SECCOMP=y'' | No | FIXME: Which services are done? Which services need to be done? How does the JSON-based configuration for procd work? How can the Seccomp BPF configurations be shared upstream? | +
-| ''CONFIG_KERNEL_NAMESPACES=y''\\ ''CONFIG_KERNEL_UTS_NS=y''\\ ''CONFIG_KERNEL_IPC_NS=y''\\ ''CONFIG_KERNEL_USER_NS=y''\\ ''CONFIG_KERNEL_PID_NS=y''\\ ''CONFIG_KERNEL_NET_NS=y'' | No | OpenWrt's procd jail feature uses namespaces. See [[https://lwn.net/Articles/531114/|LWN's series of articles on namespaces]] for more information. | +
- +
-==== TODOs ==== +
-  +
-  * Non-executable stack (NX)? MIPS support? +
-  * FIXME: Jails. What configuration options are needed to gets jails to be enabled? Which services are done? Which services need to be done? +
-    * procd reference for jail configuration options: [[http://wiki.prplfoundation.org/wiki/Procd_reference#procd_add_jail.28name.2C.5Bjail_options.5D.29]]. +
-    * Bug report stating (unverified) that jails are not working with musl on DD (x86 only?): [[https://lists.openwrt.org/pipermail/openwrt-devel/2015-November/037156.html]] and [[https://dev.openwrt.org/ticket/20785]]. +
-    * Recent jail work: [[https://lists.openwrt.org/pipermail/openwrt-devel/2015-November/037154.html]] and [[https://lists.openwrt.org/pipermail/openwrt-devel/2015-November/037511.html]] (note that there are many patches in that thread) and [[https://lists.openwrt.org/pipermail/openwrt-devel/2015-December/037597.html]] (many patches) and [[https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg35978.html]] (about improving documentation). +
-  * FIXME: ASLR. "Assigned" to Steven Barth, according to him. "Probably going to take some hacking into GCC...", but hacking GCC doesn't seem realistic. Source: [[https://youtu.be/arDdCMYNXQA?t=471]]. +
-  * FIXME: What do packages need to do to be compatible with OpenWrt's hardening configuration?  Create a security checklist for contributing a package or reviewing a contributed package. +
-  * According to various discussions, passing hardening options in CPPFLAGS is the "right" thing to do, but more packages actually work correctly if the flags are passed in CFLAGS. It would be nice if the packages could be fixed upstream could be fixed to accept hardening flags in CPPFLAGS so that OpenWrt can switch to using CPPFLAGS for this purpose. +
-  * [[https://lists.openwrt.org/pipermail/openwrt-devel/2015-March/032197.html]] - Discusses procd jails and procd seccomp-bpf support, but also has a large wishlist at the end with a lot of good ideas. +
-  * FIXME: What other projects' guidelines can/should be adopted by OpenWrt? Examples: [[https://wiki.archlinux.org/index.php/Security]] and [[https://wiki.gentoo.org/wiki/Hardened/Toolchain]]. +
- +
-===== Web Interface (LuCI, etc.) Hardening ===== +
- +
-  * FIXME: How are XSS, CSRF, and other "solved" web security vulnerability classes systematically prevented? (The OpenWireless documentation mentions some measures that they have taken, such as insisting on the use of only "safe" HTML templating patterns.) +
- +
-===== Cryptography ===== +
- +
-  * FIXME: How well does the secure random number generator work in practice? Most OpenWrt devices lack a hardware RNG and seem to have few sources of entropy. +
- +
-  * The Jitter RNG is available in Kernel 4.2 and later. DD will be based on Kernel 4.4 according to [[https://lists.openwrt.org/pipermail/openwrt-devel/2016-January/038726.html|this message from John Crispin]]. +
- +
-  * How well does the Jitter RNG work? What else can be done to improve secure random generation? Background: [[https://lkml.org/lkml/2015/6/22/112|Crypto Update for 4.2]] and the [[https://lwn.net/Articles/642166/|LWN article on the Jitter RNG]]. +
- +
-  * FIXME: Adding and preferring new algorithms & protocol versions. Should OpenWrt make a concerted effort to make a certain set of algorithms (e.g. x25519 + Ed25519 + ChaCha20 + Poly1305, NIST P-{256,384} ECDH & ECDSA + AES-{128,256}GCM) enabled and preferred by default? +
- +
-  * FIXME: Some algorithms and protocols are obsolete and/or dangerous. Are there any that should be outright disabled in the default configuration? How should security vs. compatibility in the default configuration be balanced? +
- +
-  * FIXME: Document the new Ed25519 package signing mechanism. What, exactly, is signed? Who signs packages? How are the keys managed? How are keys revoked? +
- +
-  * FIXME: The build process uses MD5 digests to ensure packages haven't been tampered with. This  protects against most kinds of tampering, but it wouldn't protect against someone intentionally developing a public "good" and a private "bad" version of a package, where the "bad" version would have the same MD5 as the "good" version. It would be good to migrate to something stronger like SHA-256 (sha256sum). +
- +
-===== Potential Future Improvements ===== +
- +
-  * FIXME: What security technologies, with what priority, are worth adding to OpenWrt? Full ASLR? SELinux (perhaps based on Android's policy)? LXC containers? +
- +
-===== LXC Containers ===== +
- +
-See the [[https://smallhacks.wordpress.com/2015/07/15/lxc-on-openwrtturris-presentation/|LXC in OpenWrt/Turris]] presentation (Video and slides) by Alex Samorukov on LXC containers. Important unanswered questions: +
- +
-  * FIXME: How are LXC containers complementary to other security mechanisms? +
-  * FIXME: How are LXC containers a better alternative for other security mechanisms?+
  
 +^ .config line                                   ^ Enabled by default  ^ Notes                                                                                                                                ^
 +| ''CONFIG_PKG_CHECK_FORMAT_SECURITY=y''         | Yes                 | ''-Wformat -Werror=format-security''                                                                                                 |
 +| ''CONFIG_PKG_CC_STACKPROTECTOR_REGULAR=y''     | Yes                 | ''-fstack-protector''                                                                                                                |
 +| ''CONFIG_PKG_CC_STACKPROTECTOR_STRONG=y''      | No                  | ''-fstack-protector-strong''                                                                                                         |
 +| ''CONFIG_KERNEL_CC_STACKPROTECTOR_REGULAR=y''  | Yes                 | Kernel config CONFIG_STACKPROTECTOR                                                                                                  |
 +| ''CONFIG_KERNEL_CC_STACKPROTECTOR_STRONG=y''   | No                  | Kernel config CONFIG_STACKPROTECTOR_STRONG                                                                                           |
 +| ''CONFIG_PKG_FORTIFY_SOURCE_1=y''              | Yes                 | ''-D_FORTIFY_SOURCE=1'' (Using [[https://git.2f30.org/fortify-headers/|fortify-headers]] for musl libc)                              |
 +| ''CONFIG_PKG_FORTIFY_SOURCE_2=y''              | No                  | ''-D_FORTIFY_SOURCE=2'' (Using [[https://git.2f30.org/fortify-headers/|fortify-headers]] for musl libc)                              |
 +| ''CONFIG_PKG_RELRO_FULL=y''                    | Yes                 | ''-Wl,-z,now -Wl,-z,relro''                                                                                                          |
 +| ''CONFIG_PKG_ASLR_PIE_REGULAR=y''              | Yes                 | ''-fPIC'' CFLAGS and ''-specs=hardened-build-ld'' LDFLAGS\\ PIE is activated for some binaries, mostly network exposed applications  |
 +| ''CONFIG_PKG_ASLR_PIE_ALL=y''                  | No                  | PIE is activated for all applications                                                                                                |
 +| ''CONFIG_KERNEL_SECCOMP''                      | Yes                 | Kernel config CONFIG_SECCOMP                                                                                                         |
 +| ''CONFIG_SELINUX''                             | No                  | Kernel config SECURITY_SELINUX                                                                                                       |
  
  • Last modified: 2024/12/07 10:05
  • by ynezz