Before we start ...
... let's do some real hacking!
Lecture 12
Protection
Thierry Sans
15-349: Introduction to Computer and Network Security
Protecting Programs
➢
How to lower the risk of a program security
flaw resulting from a bug?
•
During development
•
•
Writing safer code
Good practices in software engineering
During the execution
•
Protection of memory
•
Protection of files
•
Protection of the kernel
The OS as a shield
Part 1: During the development
➢
Writing safer code
•
The choice of the programming language
•
Modularity, encapsulation, and information hiding
•
Confinement
•
Philosophy of good programming practices
•
Testing and penetration testing
•
Static analysis
•
Formal methods for software engineering
Safe Programs
➢
➢
[Cervesato]
Do not crash
•
Even without confinement in protected memory
•
Cannot corrupt even their own memory
Cannot access arbitrary addresses
•
•
Otherwise it could open the door to attacks
The choice of the programming language
➢
[Cervesato]
Safe programs can be written in any language,
but
•
Some languages allow writing only safe programs
Safety usually ensured by type checking
•
•
Some languages isolate potentially unsafe code
•
•
Pure Lisp, pure Java, ADA, ML
Modula-3, Java with native methods, C#
Some languages are hopeless
•
Assembly languages, C
Choosing safer libraries
➢
If you choose (or have to) write a program using
unsafe programming language then
•
Use safe libraries (which are NOT the standard
libraries most of the time)
Stack-smashing protection
➢
Checking that the stack has not been altered
when a function returns
•
If it has been altered, the program exits with a
segmentation fault
•
Verification embedded into program by the compiler
•
Examples of such systems are:
•
Libsafe
•
StackGuard
•
ProPolice (gcc patches)
•
Microsoft's Data Execution Prevention
Good practice in software engineering
➢
Things that you learn in software engineering
are good for:
•
Designing complex application
•
Reusing code
•
Maintaining the program throughout its life cycle
•
Security
Modularity, encapsulation, information hiding
➢
Modularity
•
•
➢
➢
Have separate modules for separate functionalities
Easier to find security flaws when components are
as independent as possible
Encapsulation
•
Hiding implementation details to other components
•
Limits the interaction between the components
Information hiding
•
Black box model
Has been verified
wrong in practice
Be a “security aware” software designer
➢
When writing a program
•
•
•
Check the inputs, even between components that
belongs to the same application (mutual suspicion)
Be “fault tolerant” by having a consistent policy to
handle failure (managing exceptions)
Reuse known and widely used code by using design
patterns and existing libraries
Testing and Penetration testing
➢
“Regular” tests
•
➢
Check the functionalities of the program
What the program is expected to do
•
Unit test
•
Integration test
•
Performance test and so on ...
Penetration test
•
Try to make the software fail by pushing the limits
of a “normal” usage
What the program is not suppose to do
•
Lecture 16: Security Assurance
Formal methods for software verification
➢
Static analysis
•
•
➢
Analyzing the code to detect security flaws
•
Control flow structure: analyzing a sequence of instructions
•
Data flow structure: analyzing how the date are accessed
•
Data structure: analyzing how data are organized
We have mature techniques now
Abstract interpretation [Cousot]
•
Verification of critical embedded software in Airbus
aircrafts
Formal methods for software engineering
Mathematical description of the problem
More or less automated
Refinement steps
Proof of correctness
Better if the code is
generated automatically
Executable code
or hardware design
... remember 15-312 :)
Formals methods in the “real life”
➢
Formal methods are not in research labs only
but they are used for real applications
•
Hardware design (VHDL, Verilog)
•
•
Used by semi-conductor companies such as Intel
Critical embedded software (B method, Z)
•
Used for public transportation system design by Alstom
... to be completed.
Advantages and Drawbacks
➢
Nothing better than a mathematical proof
•
➢
Development is time and effort (and so money)
consuming
•
➢
A code “proven safe” is safe
Should be balanced with the time spent on testing
and on maintaining the code (patches) developed
with “traditional” methods
Do not prevent from specification bugs
•
Example: network protocols
Part 2: During the execution
➢
The OS as a shield
•
Protecting the memory
•
Confined execution context
•
Protecting the kernel system calls (Syslog)
•
Protecting the files (access control)
Memory and address protection
➢
Idea
•
•
•
Programs (and data) used the same address space
So, they should not access memory addresses that
has not been allocated to them
Therefore, as soon as a program tries to access to
an authorized memory address, an exception should
be raised
•
The well known “segmentation fault”
Segmentation
Idea: Cutting the program into pieces (segments) that can be
located dynamically wherever in the memory (useful for caching)
Security: A program can access a segment only if it appears in
the segment table
Segmentation (and paging)
➢
Good because ...
•
➢
If a program “goes crazy” it cannot affects the
memory used by other programs
But still not enough :(
•
A shell code can be inserted in the same segment
(Buffer overflow attacks)
Tagged Architecture
Idea: Tagging memory cells as data or
instructions during execution
Security: Data in a buffer cannot be
turned into a instructions like in buffer
overflow attacks
Requirements: A processor implementing
this tagging mechanism and an OS using it
Intel XD (EDB) or AMD64 NX (EVP)
+ Windows Vista
Relocation and encryption
➢
Randomize stack location and/or encrypt return
address on stack by XORing with random string
•
•
Attacker won’t know what address to use in his
string
Implemented in Windows Vista
Confined execution environment: Sandbox
➢
Idea
•
➢
A sandbox is tightly-controlled set of resources for
untrusted programs to run in
Examples
•
Web applets
•
Java applets
•
Flash applets
•
Linux's chroot
•
Virtual machines
Intrusion Detection and/or Prevention System
➢
SYSLOG: monitoring kernel system calls
•
•
Hybrid approach of intrusion detection
•
Signatures
(well known programs)
•
Learning behaviors
(unknown programs)
Prevention mode
•
•
Can block suspicious system calls
Vulnerable to malicious programs residing in the
kernel: rootkits
Conclusion
➢
What is your conclusion?
Tip of the day
➢
As a user, what should I do?
•
➢
Be updated! (not to hard nowadays)
As a system administrator, what should I do?
•
Be aware of security alerts (CERT)
•
Be updated (for minor software patch and update)
•
When a major new version appears, wait for
security experts, hackers and users to shake it
before adopting it