Security

This page contains the old content from security, please move content to the new page and do not edit this one any more.

Security Advisories & Vulnerability Reporting

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 page. On the other hand, the mailing list thread [OpenWrt-Devel] Security Vulnerability Reporting and Database indicated that security vulnerabilities be reported by sending an email to the public openwrt-devel mailing list. Whichever way it is done, it is better to report a vulnerability than not report it.

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

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

Threat Model

Security Updates

Most people set up their device once and then don't touch it, as long as it appears to be working. In particular, very few people make a habit of checking for updates.

  • FIXME: How can updates be made automatic and enabled by default?
  • FIXME: How can automatic updates be done in a non-disruptive way, as 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 particular, if 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:

Reproducible Builds

FIXME: Write this section.

Background info:

Binary-Blob-free Builds

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 reviewed. Further, 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 code. Obviously, 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.

  • FIXME: What can be done to help developers configure a 100%-binary-blob-free build?
  • FIXME: What can be done to document which binary blobs, if any, are used by a particular build?
  • 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:

General Concerns to Address

OS and Package Hardening

See the configuration files under 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:

  1. git clone https://github.com/slimm609/checksec.sh, somewhere outside your OpenWrt tree.
  2. Build OpenWrt with CONFIG_TARGET_ROOTFS_TARGZ=y so that it generates a tar.gz archive.
  3. Extract the .tar.gz archive to a temporary directory.
  4. 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 Evaluating the security of OpenWrt (part 2) for help on analyzing the output; OpenWrt has improved since that blog post was written so your results should be better.

"Hardening build options" in config/Config-build.in

Source: 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: 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 LWN's series of articles on namespaces for more information.

TODOs

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.
  • 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 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?
This website uses cookies. By using the website, you agree with storing cookies on your computer. Also you acknowledge that you have read and understand our Privacy Policy. If you do not agree leave the website.More information about cookies
  • Last modified: 2019/10/22 15:33
  • by hauke