Critical projects from the low-level/embedded space

[mrybczyn]

When reviewing the current list of critical projects, I find some important low-level and embedded ones missing. Could you please consider adding those to the list:

Updated to add descriptions and include projects from the list of @jbmaillet

Distributions:

• the Yocto Project https://www.yoctoproject.org/ - a system for creating a custom embedded distribution. Used in numerous products on the market. It includes a build system, BSP layers and related tools. Sources: https://git.yoctoproject.org/
• buildroot https://buildroot.org - a minimal Linux distribution for embedded products. Sources at https://git.busybox.net/buildroot/

Bootloaders:

• u-boot - https://www.denx.de/wiki/U-Boot/ - a popular bootloader for the embedded space. Sources at: https://source.denx.de/u-boot/u-boot
• grub - https://www.gnu.org/software/grub/ - probably the most popular bootloader. Sources at: https://git.savannah.gnu.org/cgit/grub.git
• barebox - https://www.barebox.org/ a small bootloader running on various architectures. Source at https://git.pengutronix.de/cgit/barebox

Low level system tools:

• busybox - (https://www.busybox.net/): an executable providing most of the system tools (including shells). Ubiquius, used in virtually any embedded Linux vanilla devices, for example in every domestic SOHO DSL / cable boxes, Wi-Fi routers. Most issues can be avoided by using a seriously trimmed down build configuration, but it has its bugs/CVE too.

Standard libraries:

• musl - https://musl.libc.org/ - a small libc implementation, frequently used on embedded products. Sources: https://git.musl-libc.org/cgit/musl
• dietlibc - https://www.fefe.de/dietlibc/ - a minimal libc implementation

Crypto libraries:

• mbedTLS - https://www.trustedfirmware.org/projects/mbed-tls/ - an implementation for crypto protocols with small footprint. Often used on ARM platforms, especially on low-resources systems. Sources: https://github.com/ARMmbed/mbedtls
• Mozilla nss - https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Overview - a crypto library used in projects like Firefox. How to download and build: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_Sources_Building_Testing
• libreSSL - https://www.libressl.org/ - a fork of OpenSSL in order to modernize the code base. Downloads https://www.libressl.org/releases.html

Platform-specific:

• OPTEE - https://www.trustedfirmware.org/projects/op-tee/ - the reference Trusted Execution Enviroment (TEE) implementing the Arm TrustZone. Necessary element of security on the ARM platform. How to build: https://optee.readthedocs.io/en/latest/building/index.html

• Arm Trusted Firmware: part of ARM boot chain, exist in 2 flavors depending in the architecture used:

Trusted Firmware-A: https://developer.trustedfirmware.org/w/tf_a/ A reference implementation of secure world software for Arm A-Profile systems (Armv8-A and Armv7-A), including an Exception Level 3 (EL3) Secure Monitor. It leverages Arm TrustZone technology; this is different for A and M profile systems, which is why the project has two separate codebases. Runs on every ARM based Android device.

Trusted Firmware M: https://developer.trustedfirmware.org/w/tf_m/ - A reference implementation of secure world software for Arm M-Profile systems (Armv8-M).

Networking:

• libwebsockets - https://libwebsockets.org/ - a library implementing network protocols like HTTP, MQTT, websockets. Low footprint and frequently used in embedded products.
• lwIP - https://savannah.nongnu.org/projects/lwip/ - a minimalistic network stack. Often used in systems where a typical network stack could not fit because of its' size.

[david-a-wheeler]

Can you please provide URLs for each? (Home page and/or repos)? That way we ensure we're talking about the same thing :-).

Ideally, a short 1-3 sentence statement for each on why it's important would be great, specifically justifying/giving examples to show that it's widely used or dépended on. Low-level utilities often have privileged access, so it's usually easy to argue that vulnerabilities or subversions can be bad, but we also need to argue that they're widely used. We need to record this information better in our spreadsheet for the existing ones, too.

On Dec 22, 2021, at 12:12 PM, Marta Rybczynska @.***> wrote:

When reviewing the current list of critical projects, I find some important low-level and embedded ones missing. Could you please consider adding those to the list:

Distributions:

• the Yocto Project Bootloaders:

• u-boot • grub Low level system tools:

• barebox Standard libraries:

• musl • dietlibc Crypto libraries:

• mbedTLS • Mozilla nss • libreSSL Networking:

• libwebsockets • lwIP — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you are subscribed to this thread.

[jbmaillet]

To the list above, I would add off the top of my head:

busybox (https://www.busybox.net/): for its ubiquity, used in virtually any embedded Linux vanilla devices, for example in every domestic SOHO DSL / cable boxes, Wi-Fi routers. Most issues can be avoided by using a seriously trimmed down build configuration, but it has its bugs/CVE too.

buildroot (https://buildroot.org/): often used when you don't want to use the corporate-sized Yocto, and there are reasons for this. (The company I work for did a 1-ear long industrial PoC for a major French carmaker using Yocto, and everyone one hated it with a deep passion.) (We don't use buildroot anymore either, but something similar developed in-house.)

OP-TEE (https://www.op-tee.org/): Arm Trusted Execution Environment, implementing the Arm TrustZone technology.. Run in every Android smartphone, enough said. Note that they are other implementations, commercial or not, such as the new Google's Trusty TEE, but OP-TEE, managed by Linaro IIRC, is still the reference point. OP-TEE security advisories are here.

Arm Trusted Firmware: part of ARM boot chain, exist in 2 flavors depending in the architecture used:

Trusted Firmware-A: A reference implementation of secure world software for Arm A-Profile systems (Armv8-A and Armv7-A), including an Exception Level 3 (EL3) Secure Monitor. It leverages Arm TrustZone technology; this is different for A and M profile systems, which is why the project has two separate codebases. Advisories here, but most reliable and up to date source is here. Runs on every ARM based Android device.

Trusted Firmware M: A reference implementation of secure world software for Arm M-Profile systems (Armv8-M). Advisories here.

[mrybczyn]

Updated the initial post. Big thanks to @jbmaillet for additions

[jbmaillet]

@mrybczyn you're welcome. Now that I think of it, there may be more to add to the list, for the various interfaces (= attack surface) stacks of embedded devices. But it seems difficult to identify vastly deployed software handling these. Again, from the top of my head:

• Wi-Fi: hostapd / wpa_supplicant in userland, MAC80211 in kernel space: runs on every Android phone/tablet, and AFAIK every DSL/Cable/Set top boxes. Remarkably stable BTW. Apart from this userland also have a look at CPE 'a:linux:mac80211' in the kernel.
• Bluetooth: Runs on every smartphone. Linux Bluez is doing its best, but regularly broken, would it be only because of the Bluetooth SIG specification bugs (cyber bugs in specs are a plague, and could be another topics by themselves), so much so that Google decided to make its own Bluetooth stack from scratch about 10 years ago. Don't approach BT without a 10 feet pole, it as become so complex it is broken 2-3 times per year as a whole.
• USB. Everywhere. Use USB condoms on every untrusted hosts.
• GPS: there are some juicy attack scenarios there. On Linux the reference implementation is by Eric S. Raymond, plus tons of proprietary implementations by Garmin gizmos and the like. I might check for Android implementation, drop me a line if I am slow to respond.
• NFC: on every non-prehistoric smartphone, I don't know much about it.
• Ethernet / TCP/IP: on every DSL/cable/domestic routers and now automotive network. Not much to say about it. There have been CVE in the IPv6 specification though. Nonetheless, the whole stack of AV/TSN networking has become critical in some applications like automotive: synchronizations of cameras to screens, radars/lidars/vehicle to vehicle/vehicle to infrastructure/5G etc: think of it as NTP on steroids, especially IEEE 802.1AS-2011. This is not only cybersec critical, but safety critical as well: cars are cyber physical systems, weighting more than a ton, running at more than a 100km/h, with people inside and around (just speaking of what I know about, I guess this apply to a lot of others industries, for ex civil aviation and industrial systems).
• Industry-specific buses / interfaces: for example CAN for the automotive industry, designed in the early 80s (enough for cybersec said) there are probably others for military / aerospace avionics (military or civil is just the same here), medical, industrial OT. Also industry-specific diagnostic port, such as OBD, which is a big joke.
• SELinux: runs on every Android phone, and in my company on plain vanilla embedded Linux products as well. It has its issue from time to time, for example have a look at these CPE (some are deprecated):
  • 'a:canonical:selinux'
  • 'a:fedoraproject:selinux-policy'
  • 'a:kernel:selinux'
  • 'a:redhat:openstack-selinux'
  • 'a:selinuxproject:policycoreutils'
  • 'a:selinux_project:selinux'
  • 'a:selinux:setroubleshoot'
  • 'o:selinux_project:selinux'
  • (also note that some other players are rather relying on SMACK instead, such as AGL, but I would say the industrial footprint is very low - sorry for the Linux Foundation AGL ;-) )
• (I won't mention hypervisors here, there tons of proprietary implementations in the embedded space and we are focused on OSS.)
• (Radio, would it be DAB / DVB / SDR for good old broadcasting, or 5G/6G/... for telephony might be of interest too, but I am not aware of the state of the Art OSS implementations. I have colleagues more knowledgeable than me about this if needed.)

I think at last Wi-Fi and Bluetooth could require a careful examination.

[Amir-Montazery]

suggestions have been added to "Community/OpenSSF Member Additions" portion for discussion and consideration at a future workgroup meeting.