Security on Open Source
Content
Security Validation on Open Source Projects
Costel Maxim
Security Validation Engineer, Intel
1
The following discriminators push towards open source
Reliability/stability/scalability are critical
Correctness of design and implementation
The software is critical to the user’s control of the business.
The software establishes or enables a common computing and
communications infrastructure
2
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
3
Security in open source
December 2004, Wired Magazine
January 2008, Department of
Homeland Security
20–30 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
4
Security Requirements
Secured infrastructure
Free source code for everybody
Defined work flow
Design and influence
5
Intel met Android
6
Android* Security
Security model
Sandboxed applications – direct interaction between
applications is prevented
Each application requires a specific rules set
Encryption
Android Security Issues
7
Security Validation activities done for Android*
Features validation
Static code analysis
Secure boot
DRM
Whole disk encryption
Common Vulnerabilities and Exposures
8
Tizen*
Linux based
HTML5, CSS3, JavaScript
Tizen* Web API
AppUP
SDK, Simulator, Emulator
Smartphone, Tablet, Netbook, Smart TV, IVI
Open source community contribution
9
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
Costel Maxim
Security Validation Engineer, Intel
1
The following discriminators push towards open source
Reliability/stability/scalability are critical
Correctness of design and implementation
The software is critical to the user’s control of the business.
The software establishes or enables a common computing and
communications infrastructure
2
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
3
Security in open source
December 2004, Wired Magazine
January 2008, Department of
Homeland Security
20–30 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
4
Security Requirements
Secured infrastructure
Free source code for everybody
Defined work flow
Design and influence
5
Intel met Android
6
Android* Security
Security model
Sandboxed applications – direct interaction between
applications is prevented
Each application requires a specific rules set
Encryption
Android Security Issues
7
Security Validation activities done for Android*
Features validation
Static code analysis
Secure boot
DRM
Whole disk encryption
Common Vulnerabilities and Exposures
8
Tizen*
Linux based
HTML5, CSS3, JavaScript
Tizen* Web API
AppUP
SDK, Simulator, Emulator
Smartphone, Tablet, Netbook, Smart TV, IVI
Open source community contribution
9
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
