Ostro™ OS Security Threat Analysis🔗
The Ostro™ OS security model aims to utilize standard components, be simple and easy to understand, and allow extensibility and scalability. Our focus is more on protecting the IoT device from network attacks and less on protecting against malicious users and application developers.
This document defines the main security threats and our solutions to them. It also describes additional security mechanisms that can be used for device types that have different requirements.
For a more general introduction to Ostro OS and its architecture see the Ostro™ OS System and Security Architecture document.
Here are some terms used within this document.
|IOT||Internet of Things|
|DAC||Discretionary Access Control|
|MAC||Mandatory Access Control|
|CVE||Common Vulnerabilities and Exposures|
|API||Application Programming Interface|
|(N|H)IDS||Network or Host Intrusion Detection System|
|IMA||Integrity Measurement Architecture|
|CPU||Central Processing Unit|
|NFC||Near Field Communication|
|USB||Universal Serial Bus|
|WAN||Wide Area Network|
|(W)LAN||(Wireless) Local Area Network|
|TLS||Transport Layer Security|
|URL||Uniform Resource Locator|
|TPM||Trusted Platform Module|
|OEM||Original Equipment Manufacturer|
There is no “one solution that fits all” when talking about IoT security. Devices using the Ostro OS will vary greatly depending on their planned use, and there will be many Ostro OS use cases that we cannot even see yet. Devices may also have secondary and tertiary use cases outside of their originally planned environment. Thus, we will provide (pre-configured) mechanisms and templates for supported use cases and help our customers provide systems with maximum security and minimum hassle.
Most IoT devices will have just a single application and not have access to an application store. This is also the use case that Ostro OS security is optimized for. Compared to say, a mobile phone OS, the Ostro OS security focus is moved from application security to network security. However, the security is planned to be scalable. If there is a problem that the default security setup does not cover, the security can be stepped up by adding components and configuration.
In addition, supporting multiple real users of the same device is less important and left to applications to support. Therefore the Ostro OS security model can use Unix users to distinguish between different applications.
The Ostro OS will also provide clear documentation on how the security is done and how it is expected to be extended or scaled. Especially covered are the places where the security model differs from baseline Linux security that can be expected from any mainstream desktop Linux distribution.
Extensions to the support included in the Ostro OS itself is also listed, primarily to document which additional methods were also considered and excluded from the Ostro OS scope. If desired, an OEM can add these additional methods, for example by recompiling or reconfiguring the Ostro OS, but the Ostro OS itself will not provide additional hooks for all of them.
Top-Level Security Challenges🔗
|Persona||Motivation||Attacker type||Starting privilege level||Skill and potential effort level|
|Ostro OS download and update infrastructure attacker||Damage vendor’s brand; personal reputation; access to user data and device||Network adversary||Low||High|
|Authorized device user||Override behavior defined by the service provider||Local physical access||Medium||Medium|
|Malicious unauthorized device user||Steal the physical device or data in it||Local physical access||Low||Varies|
|Network attacker (MITM attacker, script kiddie, botnet owner, etc.)||Access to user data and device; reputation||Network adversary||Low||Varies|
|Authorized malicious project team admin||Insider who wants to harm||Authorized adversary||High||Low|
|Malware developer||Access to user data and device; reputation||Local, non-physical access (application intentionally gets installed or code injected into the device||Medium||High (code injection), Medium (app developer)|
|Group||Description||Business impact if compromised (worst case)||Who should have access (Trust Model)||Attack Points|
|Sensor data and actuators||Microphone, camera, temperature, heating control, lighting ...||High||System components and applications according to their manifest privileges||Device|
|Application data||Log files, stored sensor data, media files, application credentials/keys||Medium||Individual applications||Device|
|System data and files||credentials/keys, service configuration, executables and libraries||Medium||System components (read/write), applications (read-only)||Device|
|Access||Privileged API access||Medium||System components and applications according to their manifest privileges||Device|
|Releases and tools||Ostro OS releases||Medium||Release manager, developers||Hosting web sites|
|Local network||UPnP protocol, other devices||Medium||Authorized users and applications||Device|
|Device resources||CPU, memory, disk space||Medium||Applications and system components||Device|
The “Attack Points” column distinguishes between assets accessed through the device (and where Ostro OS itself must protect the assets), and other assets (where mitigation must happen elsewhere).
|System Element||Compromise Type(s)||Assets exposed||Attack Method|
|Ostro OS update mechanism and servers||Data modification||System files||Network attack|
|Ostro OS installation||Data modification||System files||Physical or network attack|
|User device (file system, databases)||Data modification, elevation of privilege||Application and system data||Physical access, malware|
|Applications and services running on user device||Elevation of privilege||Application and system data||Malformed input, man-in-the-middle|
|Cloud service, other trusted devices||Data modification||Application and system data||Attack on the remote device or service|
|Bluetooth, other connectivity services||Data confidentiality, Data integrity||Application and network data||Network attack, malformed input|
Note that Ostro OS also includes a variety of mechanisms intended for developer use and debugging. While we have attempted to show developers how to use these modes of access in the safest method possible, they could be used as additional attack surfaces if left open in final products.
|Name||Adversary||Asset||Attack method and pre-conditions|
|Lib-1||Malware developer/ Network attacker||System code and files||Exploiting a local or remote vulnerability in privileged Ostro OS code|
|Lib-2||Malware developer/ Network attacker||Application data||Exploiting a local or remote vulnerability in an application or Ostro libraries the application uses|
|Lib-3||Network attacker||Application data, sensor data, system data||Pre-condition: attacker is able to upload a binary or runnable code to the system. Method: attacker executes a malicious binary or runnable code in the system|
|Lib-4||Network attacker||System data||An attacker can access the device when it’s being provisioned (taken into use) because of insecure network provisioning or insecure default configuration|
|Lib-5||Download and Infrastructure attacker||Releases and tools||Attacker has managed to compromise an Ostro OS update server|
|Lib-6||Authorized device user / Malicious unauthorized device user||System data, application data||Authorized or unauthorized user interferes with device boot and operation|
|Lib-7||Authorized device user||System data||Attacker reverts platform software to an earlier version that contains vulnerable software|
|Net-1||Network attacker / Malware developer||Local network||A malicious or compromised application or service threatens the internal network|
|Net-2||Network attacker||Application / system / sensor data going over the network||Man-in-the-middle attack|
|Net-3||Malware developer||Sensor data||An Ostro OS-based network gateway is configured to collect sensor data, but a networked sensor bypasses the gateway to transmit data directly to Internet|
|App-1||Malware developer / Network attacker||Application data||A malicious or compromised application reads another application’s private data or wants to kill or debug another application|
|App-2||Malware developer / Network attacker||Device resources||A malicious or compromised application consumes all CPU, disk space or memory|
|App-3||Malware developer / Network attacker||Access; sensor data||A malicious or compromised application tries to access a sensor or actuator that it has no right to access|
|API-1||Malware developer||System or application data||Pre-condition: attacker is able to upload a binary or runnable code to the system. Method: use kernel interfaces for privilege escalation|
|API-2||Malware developer||System data||Unauthorized access to middleware APIs|
|API-3||Malware developer||Application data||Application misrepresents another application towards cloud|
Threat details and mitigation🔗
A security bug is discovered in an Ostro component that runs with privileged access.
The most important thing is getting the security bug fix to the client devices as quickly as possible. We need to set up a process for tracking CVEs. If an upstream bug fix doesn’t get to oe-core or is otherwise delayed, we need to do the fix directly in the Ostro OS. The security fixes need to be communicated quickly to the customers, so that they will understand the real impact of the problem. The Ostro component selection should be partially based on the component security track record. This means we should avoid components with slow bug fix times or a history of security incidents, if possible.
To mitigate the risk we should reduce the amount of privileged code that is run in the system. We should make sure that we are running a minimal configuration of a privileged service, disabling unused plugins and extensions and using a conservative service configuration. If possible, the system services should isolate the parts that need privileged access to a separate sub-component and run the rest of the service as user privileges. Systemd can be used to drop unneeded capabilities, thus limiting the potential damage. For services which don’t need admin capabilities, Systemd can also be configured to prevent service from accessing
ProtectHome=true, thus protecting user data. In addition, systemd
ProtectSystem=fullshould be used to mount
/etcread-only when possible.
Select the outward facing services carefully. Use well-tested libraries, have sensible configuration for services, pay attention to the security history, and try to write little custom code.
Use a HIDS to detect intrusions in the system. An example of such a tool is Samhain (http://www.la-samhna.de/samhain/) or even IMA with log file monitoring. In case of a detected intrusion, reboot the device to a predefined fault target, which can for example restore the device to factory settings or alert the user.
Use systemd’s support for service-private
Investigate Yocto Project support for various build-time security mechanisms, such as position-independent executables, FORTIFY_SOURCE, address space layout randomization, and glibc heap protector. Allow these to be turned on or off, depending on the performance characteristics of the system in development.
Use MAC for giving system services more fine-grained access to system files.
Test the selected Ostro OS network services with fuzzing and static analysis to find the bugs.
An application needs to provide services to the network, opening an attack channel to the system.
To prevent the attack, limit access to services with a firewall. This allows the system administrator to make it possible to connect to the system by only a limited IP address range, for example. Limit what the applications can do by using access control mechanisms, such as Unix groups, for accessing platform features.
Only enable required network protocols and avoid using networking protocols that do not include security mechanisms.
Attacker is able to upload a binary or runnable code to the system.
Mount root filesystem read-only to prevent easy installation of malicious binaries there. Set the data partition and tmpfs to have a noexec flag. Use code signing (IMA) to verify binaries.
For interpreted languages the situation is bit more complex. Interpreted languages are not affected by noexec, since the interpreter will generally reside in the root filesystem. They need to do the required changes inside the interpreter, so that running unsigned scripts is not allowed. The script signatures must be checked by the runtime. Especially code downloaded from Internet (by importing it directly or downloading it from the script) must not be ever run if a corresponding cryptographic signature does not validate.
An attacker can access the device running the Ostro OS when it’s being provisioned (taken into use) because of insecure network provisioning or insecure default configuration.
Support key management through USB and NFC physical access methods. This can be done by providing first-boot network configuration authentication by using the URL returned by NFC. URL parameters contain the authentication token. For provisioning by starting the device in WLAN access point mode, use a generated device-unique key, which is provided as string or QR-code.
The configuration can also be pulled from a pre-configured cloud service using a special token that is added to the device during production and is accessible from software.
Attacker has managed to compromise an Ostro OS update server.
Clear Linux* update mechanism (also used by the Ostro OS) signs each file, so updater sees if the files have been tampered with.
Notification mechanism. If swupd is used wrapped in Soletta, it will report back to the caller about the error. The caller must then notify the user or do other appropriate actions based on pre-configured policies, such as changing the update mirror.
Authorized or unauthorized user interferes with device boot and operation.
Attacker reverts platform software to an earlier version that contains vulnerable software.
Software update must not allow going backward in version numbers. In case of factory reset, the device should attempt to upgrade itself to the latest version available before exposing services to the network.
A malicious or compromised application threatens the internal network.
Use a firewall to filter access to the network. It’s possible to tag IP packets belonging to a certain user (iptables –uid-owner $UID). Configure firewall to give the application access only to the IP ranges that it needs to access. If the application runs in a container, the application will have a virtual interface in the container and the host can control routing packets from the interface with the firewall.
PrivateNetwork=yescan completely disable network access when it is not needed.
Use MAC-based network labeling.
Attacker is disguised as a trusted resource outside the device running the Ostro OS.
Support DNSSEC to avoid cache poisoning and man-in-the-middle attacks. Utilize TLS 1.2 and device side certificates, and include support for client certificates. Support OAuth, Kerberos 5 and other multi-party authentication and authorization mechanisms.
Certificate management (including certificate revocation) needs to be supported.
Have a notification mechanism to tell the user when a remote certificate issue is found. Define customizable policies on what to do in this case.
An Ostro OS-based network gateway is configured to collect sensor data, but a networked sensor bypasses the gateway to transmit data directly to Internet.
Proper sensor provisioning helps to prevent accidental sending of data to the network. The Ostro OS is not by default preventing sensors from accessing the Internet.
Configure firewall to block access of certain protocols that are often used to access IoT services (CoAP, MQTT). Prevent access to the data gathering addresses of well-known cloud services. Note that if legitimate non-whitelisted traffic from the private network is supposed to go to Internet, it’s not feasible to completely solve the issue.
A malicious application reads another application’s private data. A malicious application wants to kill, debug or manipulate another application.
Applications run under different Unix IDs.
Containers separate applications.
Smack as MAC can prevent accidental sharing of data between applications (incorrect protection bits).
Applications can share data with each other by belonging to a suitable sharing group (such as “media”). Users belonging to that groups can read and write to a directory in a shared area. Applications wishing to share more between each other must be started as the same user, which enables them to access each other’s data in the application data directory. If two applications want to share data and be containerized, they need to come from the same package (have a common manifest).
A malicious or compromised application consumes all CPU, disk space or memory.
During root file system creation, reserve some disk space for root to use. If applications are run inside containers, set reasonable CPU and memory limits for the container using cgroups.
Support quotas for user disk space limiting.
A malicious or compromised application tries to access a sensor or actuator that it has no right to access.
For local sensors, use DAC groups for controlling access to files in
sysfs. Configure Udev to set proper owners, groups and permissions to the files controlling kernel access to local sensors, such as
For remote sensors, use Soletta to access the sensors. Open Connectivity Foundation (OCF) defines a security model which Soletta implements. The application can use Soletta features for secure provisioning of sensors. For more complex authentication needs, applications need to carry the burden by having authorization mechanism such as a certificate for accessing pre-configured sensors.
More remote sensor security models can be implemented by adding support for them to Soletta.
Unauthorized access to kernel APIs, for example for privilege escalation.
Use seccomp from manifest / systemd service files.
Unauthorized access to middleware APIs to trigger actions (like system shutdown) or access information (status signals, queries).
Traditional DAC-based D-Bus access management. Disable unused (or unusable) system services.
Patch upstream services depending on PolicyKit or shim that emulates PolicyKit (for example, based on Cynara).
Application misrepresents another application towards cloud by stealing or guessing the information needed by the authorized application to identify itself.
Offer a secure storage mechanism that applications can use, for example gSSO or a TPM.
Threats and Attack Vectors Out of Scope for Ostro OS 1.0 Release🔗
- external DoS
- attack from compromised cloud (actuation, configuration, …)
- malicious activity in local network
- preventing access to the update server
- unauthorized upload of private data
- sensor DoS
- unauthorized access to sensor (on server/sensor side)
- attack using malicious data from a compromised sensor
- attacks that can affect the hardware, like causing a device to overheat
- attack vectors based on hardware that is specific to certain devices (like USB ports)
- attack vectors caused by debug modes left enabled in final products