Secure programming of resource constrained devices

Jens Getreu

2018-01-16

Agenda

Resource Constrained Devices
The Heartbleed vulnerability
The Rust Programming Language
Conclusion and recommendations

Resource constrained devices

Definition

Resource constrained device

is a computer with very limited processing and storage capabilities, designed for low energy consumption.

Examples

Wireless Sensors
The “Things” in the Internet of Things

Hardware

Software architecture

Special requirements

Resource constrained devices are vulnerable

I list here some famous attacks: the Mirai botnet in September 2016, followed by its more sophisticated successors by IoT reaper and IoTroop and last not least the Heartbleed vulnerability which is to the present day unique in its damage.

Mirai

Starting in September 2016, a spree of massive distributed denial-of-service (DDoS) attacks temporarily crippled Krebs on Security [46], OVH [43], and Dyn [36]. The initial attack on Krebs exceeded 600 Gbps in volume [46] — among the largest on record. Remarkably, this overwhelm- ing traffic was sourced from hundreds of thousands of some of the Internet’s least powerful hosts — Internet of Things (IoT) devices — under the control of a new botnet named Mirai.

We track the outbreak of Mirai and find the botnet infected nearly 65,000 IoT devices in its first 20 hours before reaching a steady state population of 200,000– 300,000 infections.

IoT reaper / IoTroop

No longer crack any weak password, only exploit IoT devices vulnerabilities;
A LUA execution environment integrated, so more complex attacks can be supported and carried out;
Scan behavior is not very aggressive, so it can stay under the radar.

Heartbleed

(see next slide)

Attacks

Mirai (2016) / IoT reaper / IoTroop / Heartbleed (2014)

Causes

RCD are as complex
Internet connectivity does not generate excess profit.

-> Devices are poorly configured and highly insecure
C/C++ do not provide memory and thread safety

The Heartbleed vulnerability

Memory safety related vulnerabilities

Heartbleed

Never has a software bug has left so many private keys and other secrets exposed to the Internet for such a long time so easy to exploit without leaving any trace.

It sounds like science fiction: 4 missing lines in a computer program compromised at least one quarter of the Internet’s cryptographic infrastructure!

The proportion of vulnerable Alexa Top 1 Million HTTPS-enabled websites have been estimated as lying between 24–55% at the time of the so called Heartbleed vulnerability disclosure [10, p. 4]. Another study found “that the heartbeat extension was enabled on 17.5% of SSL sites, accounting for around half a million certificates issued by trusted certificate authorities. These certificates are consequently vulnerable to being spoofed (through private key disclosure), allowing an attacker to impersonate the affected websites without raising any browser warnings [11].”

The Heartbleed vulnerability, listed as CVE-2014-0160 , was publicly dis- closed on 04/07/2014. The bug had been introduced with a minor SSL/TLS protocol extension called Heartbeat in January 2012. From the beginning the vulnerability had been widely exploited.

*Heartbleed is a so called memory safety bug. These bugs are very common in system programming, 2/3 of all Linux ….

Memory safety is the state of being protected from various software bugs and security vulnerabilities when dealing with memory access, such as buffer overflows and dangling pointers.[1]

For example, Java is said to be memory-safe because its runtime error detection checks array bounds and pointer dereferences.[1] In contrast, C and C++ support arbitrary pointer arithmetic, with no provision for bounds checking,[2] and thus are termed memory-unsafe.[3] [wikipedia]*

2/3 of all Linux kernel vulnerabilities are memory safety related.

CWE ID	Name
120	Buffer Copy without Checking Size of Input
125	Out-of-bounds Read
126	Buffer Over-read
122	Heap-based Buffer Overflow
401	Memory Leak

The Heartbeat TLS Extension 1

The Heartbeat TLS Extension 2

The Heartbleed vulnerability 1

The Heartbleed vulnerability 2

Vulnerable C code

unsigned char *p = &s->s3->rrec.data[0], *pl;                                    
unsigned short hbtype;                                                           
unsigned int payload;                                                            
unsigned int padding = 16;                                                       
                                                                                 
hbtype = *p++;      //<1>                                                        
n2s(p, payload);    //<2>                                                        
pl = p;                                                                          
                                                                                 
//... folded lines ...                                                           
                                                                                 
if (hbtype == TLS1_HB_REQUEST)                                                   
        {                                                                        
        unsigned char *buffer, *bp;                                              
        Cint r;                                                                  
                                                                                 
        buffer = OPENSSL_malloc(1 + 2 + payload + padding); //<3>                
        bp = buffer;                                                             
                                                                                 
        *bp++ = TLS1_HB_RESPONSE;    //<4>                                       
        s2n(payload, bp);            //<5>                                       
        memcpy(bp, pl, payload);     //<6>                                       
                                                                                 
        r = ssl3_write_bytes(s, TLS1_RT_HEARTBEAT, buffer,                       
                3 + payload + padding);  //<7>

As you can see there is an if statement missing just before the memcpy call that validates the payload length field.

Humans do these kind of mistakes. And as we can see in this example C does not help much avoid them. The reason is that C is a very old programming language that has excellent semantics to express what a program should do, but which is no very explicit to express what a program should not do.

Read type Byte from TLS Request.
Read payload-length-field form TSL Request. Note that there is no revious check if the actual payload string in TLS Request is as long as he payload-length field pretends it is!
Allocate memory for the TLS Response.
Write the type in the response buffer.
Serialise the payload-length into the response buffer.

Copy `payload`-length number of Bytes from the request buffer into the

response buffer. + -> Buffer over-read vulnerability!

The Rust programming language

Features

guaranteed memory safety
zero-cost abstractions
threads without data races

References: Firefox 57, Maidsafe, Parity-Bitcoin-Client

Could Heartbleed have happened with Rust?

fn tls1_process_heartbeat (s: Ssl) -> Result<(), isize> {
  const PADDING: usize = 16;

  let p = s.s3.rrec;
  let hbtype:u8 = p[0];
  let payload:usize = ((p[1] as usize) << 8) + p[2] as usize; // <1>

  let mut buffer: Vec<u8> = Vec::with_capacity(1+2+payload+PADDING);
  buffer.push(TLS1_HB_RESPONSE);
  buffer.extend(p[1..1+2].iter().cloned());                   // <2>
  buffer.extend(p[3..3+payload].iter().cloned());             // <3>

  let mut rng = rand::thread_rng();                           // <4>
  buffer.extend( (0..PADDING).map(|_|rng.gen::<u8>())
        .collect::<Vec<u8>>() );

  if hbtype == TLS1_HB_REQUEST {
      let r = ssl3_write_bytes(s, TLS1_RT_HEARTBEAT, &*buffer);
      return r
  }
  Ok(())
}

Heartbleed exploit package

    let s: Ssl = Ssl {
        s3 : Rrec{
                rrec:  &[TLS1_HB_REQUEST, 1, 1, 14, 15, 16, 17,
                         18, 19, 20, 21, 22, 23, 24, 25, 26, 27,
                         28, 29, 30, 31, 32]
        }
    };
    tls1_process_heartbeat(s).unwrap();
    }

System response after Heartbleed attack

    thread '<main>' panicked at 'assertion failed: 
    index.end <= self.len()',
    Process didn't exit successfully: 
    `target/release/heartbeat` (exit code: 101)

Resource sharing in Rust

Resource sharing type	Aliasing	Mutation	Example
move ownership	no	yes	`let a = b`
shared borrow	yes	no	`let a = &b`
mutable borrow	no	yes	`let a = &mut b`;

Rust Operating Systems

TockOS architecture RTFM architecture
TockOS versus RTFM

Tock-OS

Tock-OS primitives

struct App {
    count: u32,
    tx_callback: Callback,
    rx_callback: Callback,
    app_read: Option<AppSlice<Shared,u8>>,
    app_write: Option<AppSlice<Shared,u8>>,
}
pub struct Driver {
    app: TakeCell<App>,
}

new_app () {
    ...
    driver.app.map(|app| {app.count = app.count + 1});
}

As a result, TakeCell is a form of mutual exclusion. Like a mutex, TakeCell ensures that there is only one mutable reference to the internal value. However, unlike a mutex, it skips the operation instead of blocking.

The kernel relies on the following four Rust abstractions that use unsafe code: Bounds checks:

Arrays are bounds-checked, so unsafe code uses the length field to ensure accesses are safe.
Iterator optimizations: The canonical way to operate across Rust arrays is with iterators, which use unsafe code to avoid unnecessary intermediate checks.
Compiler intrinsics and primitive casts: Floating point, volatile loads/stores and casting between primitive types have architecture specific details that Rust relies on LLVM for.
Cell: An abstraction that encapsulates data such that interior references cannot escape and it can be operated on with an immutable reference.

Real Time for the Masses

RTFM primitives

threshold.raise(
    &SHARED, |threshold| {
        let shared = SHARED.access(priority, threshold);
        shared.mode.set(Mode::Bounce)
    }
);

Rust in embedded systems

Challenges

secure concurrency
- (lightweight) threads
- interrupt driven
“zero zero” cost abstractions
yet only few drivers available
yet only few platforms are supported
no std-library

Conclusion and recommendation

Limitations

Rust for Resource Constrained Devices:
Technology is mature, ready for production.

only few drivers are available
only few platforms are supported

Doable, typical amount of lines of code 10k
(vs Linux Kernel 4.14: 25 Mio lines)

Opportunities

Rust eradicates memory safety related vulnerabilities,
improves systematically the security of

field sensors
consumer IoT

Contribute to Free and Open Source Software.

Would like to close with an appeal to your community, “Contribute to….”

“… This way you can improve our homeland security in which IoT represents the one of the biggest threads, as Mirai showed impressively.”

TPM and USB authentication fobs platforms not supported yet; LLVM targets are yet missing.

TPM: TPM (Trusted Platform Module) is a computer chip (microcontroller) that can securely store artifacts used to authenticate the platform (your PC or laptop). These artifacts can include passwords, certificates, or encryption keys. A TPM can also be used to store platform measurements that help ensure that the platform remains trustworthy. Authentication (ensuring that the platform can prove that it is what it claims to be) and attestation (a process helping to prove that a platform is trustworthy and has not been breached) are necessary steps to ensure safer computing in all environments. Trusted modules can be used in computing devices other than PCs, such as mobile phones or network equipment.
USB authentication fobs: Key fobs are among a class of physical security tokens that includes smart cards, proximity cards and biometric keyless entry fobs. Hardware tokens are often small enough for users to store on a key ring, in their wallet or in their pocket. If a key fob is stolen or lost, it is more likely to be noticed immediately than a compromised password. How a key fob is used in multifactor authentication In the enterprise, key fobs are used to enable two-factor and multifactor authentication and to safeguard access to a company’s network and data. In typical deployments, a user first enters a personal identification code (PIN) to log in to the network, followed by a pseudo-random token code generated by the key fob to gain access into the system or network.

Thank you!

References

Articles

A. Levy, B. Campbell, P. Dutta, B. Ghena, P. Levis, and P. Pannuto, “The Case for Writing a Kernel in Rust,” in Proceedings of APSys ’17, Mumbai, India, 2017, p. 7.
M. Antonakakis et al., “Understanding the Mirai Botnet,” in Proceedings of the 26th USENIX Security Symposium, Vancouver, 2017, pp. 1093–1110.
R. Clayton, “A New IoT Botnet Storm is Coming,” Check Point Research, 19-Oct-2017. [Online]. Available. [Accessed: 19-Dec-2017].

Picture Credits 1

“File:STM32 Blue Pill perspective.jpg - STM32duino wiki.” [Online]. Available [Accessed: 12-Dec-2017]
Eclipse IoT Working Group, “The Three Software Stacks Required for IoT Architectures - IoT software requirements and how to implement them using open source technology.” The Eclipse Foundation, Sep-2016 [Online]. Available.
A. Avižienis, J.-C. Laprie, B. Randell, and C. Landwehr, “Basic concepts and taxonomy of dependable and secure computing,” Dependable and Secure Computing, IEEE Transactions on, vol. 1, no. 1, pp. 11–33, 2004.

Picture Credits 2

T. B. Lee, “How does the Heartbleed attack work?,” Vox, 10-Apr-2014. [Online]. Available. [Accessed: 14-Jan-2018].
“Tock Design,” [The] Tock Embedded Operating System. [Online]. Available. [Accessed: 14-Dec-2017]
J. Aparicio, “Fearless concurrency in your microcontroller,” Embedded in Rust. 09-May-2017 [Online]. Available. [Accessed: 17-May-2017]