You are on page 1of 19

Security Validation on Open Source Projects

Costel Maxim
Security Validation Engineer, Intel

The following discriminators push towards open source

Reliability/stability/scalability are critical


Correctness of design and implementation
The software is critical to the users control of the business.
The software establishes or enables a common computing and
communications infrastructure

Things need to keep the wheels moving

Well defined goals


Do not skip the crucial details
Motivated and organized people
Resources needed to sustain the project

Security in open source

December 2004, Wired Magazine

January 2008, Department of


Homeland Security

2030 bugs in proprietary software


(Carnegie Mellon University Cylab)

One bug in proprietary software


0.127 bugs in the Linux 2.6 kernel

0.17 bugs in the Linux 2.6 kernel


(Stanford University/Cover

0.14 bugs in Apache


0.041 bugs in PostgreSQL
Zero bugs in gcc

Security Requirements

Secured infrastructure
Free source code for everybody
Defined work flow
Design and influence

Intel met Android

Android* Security

Security model
Sandboxed applications direct interaction between
applications is prevented
Each application requires a specific rules set
Encryption
Android Security Issues

Security Validation activities done for Android*


Features validation

Static code analysis


Secure boot
DRM
Whole disk encryption
Common Vulnerabilities and Exposures

Tizen*

Linux based
HTML5, CSS3, JavaScript
Tizen* Web API
AppUP
SDK, Simulator, Emulator
Smartphone, Tablet, Netbook, Smart TV, IVI
Open source community contribution

Tizen security model

SMACK is the Simplified Mandatory Access Control Kernel.


Applications are running in a sandbox - isolated
Controlled access to resources smack label

Minimum privileges
Standard applications run with the same ID and non root access

10

Tizen Manifest example


<define>
<domain name="Camera" policy="shared" />
<provide>
<label name=Camera::statistics />
<description>A new label for labelling camera statistic
data</description>
<labelname=Camera::timings />
<description>A new label for labelling camera data that
contains information about timings</description>
<label name=Camera::public />
<description>A new label for labelling camera public
data</description>
</provide>
</define>
11

Tizen Threat Model

12

Security Development Lifecycle Process

The purpose of your engineering project is to


produce a product; the Security Design Lifecycle
(SDL) process enables the project team to produce a
secure project.

13

Security Development Lifecycle Process

14

Requirments: Crypto and Key Management

15

DO NOT develop or implement your own cryptographic protocols or algorithms without Security
Architecture Forum (SAFE) review.
When using hashing features, select only the SHA-2 algorithm. Source code available at RFC6234
When using HMAC, use only FIPS PUB-198 approved HMAC algorithms.
When implementing a PRNG or DRBG product, conform to NIST SP800-90.
Use AES algorithm for symmetric encryption.
Do not use Electronic Code Book (ECB) mode on data sizes of more than a single block, when using
AES.
Use RSA for digital signatures
Use RSA or Diffie-Hellman for key exchange.
When implementing RSA functions, conform to ANSI X9.31 and PKCS #1 specification.
Cryptographic keys shall be used for only one purpose.
Follow protection requirements for keys during distribution and storage.
Follow key backup and recovery requirements.
When selecting a cryptographic provider, use hardware based crypto when available.
All traces of cryptographic keys shall be destroyed as soon as the key is no longer required.
When architecting a solution, a key replacement strategy is required.
Debug/Test keys should be different than the production keys.
Ensure cryptographic keys or secret data are not extractable via scan or debug channels.

Requirments: Secure Architecture


Architect secure update mechanisms.
Security components should be designed to fail intelligently.

When designing complex products, use identification, authentication,


authorization and secure communication when necessary.
Minimize the attack surface by removing unnecessary components,
APIs, entry point, privilege levels, etc.
Limit the number of applications that require administrator or root
privileges.

16

Requirments: Software Security

17

Follow secure review guidelines during review of the high risk code.
Follow industry secure coding guidelines
Release build code should be free of backdoors.
Avoid embedding secrets in the code
Use the most restrictive data types for parameters.
All debug and observability capabilities should be removed, disabled or
secured prior to shipment.
Initialize all variables in your code.
All code that consumes memory should properly free itself at all exit
points.
To avoid race conditions use thread safe libraries, avoid shared resources
between threads and use mutex if available
For all code written in C / C++ / Java use the Klocwork Static Analysis suite
or comparable tool.

18

Bad Use of Encryption!

Thank you
19