Lecture 12
Protection
Thierry Sans
15-349: Introduction to Computer
and Network Security
Protecting Programs
➢
How to lower the risk of a program security
faw resulting from a bug?
•
During development
•
•
Writing safer code
Good practices in software engineering
During the execution
•
Protection of memory
•
Protection of fles
•
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
•
Confnement
•
Philosophy of good programming practices
•
Testing and penetration testing
•
Static analysis
•
Formal methods for software engineering
Safe Programs
➢
➢
[Cervesato]
Do not crash
•
Even without confnement 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
Verifcation 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 fnd security faws 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 verifed
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 tests
•
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 verifcation
➢
Static analysis
•
Analyzing the code to detect security faws
•
•
➢
Control fow structure: analyzing a sequence of
instructions
•
Data fow structure: analyzing how the date are accessed
•
Data structure: analyzing how data are organized
We have mature techniques now
Abstract interpretation [Cousot]
•
Verifcation of critical embedded software in Airbus
aircrafts
Formal methods for software engineering
Mathematical description of the problem
More or less automated
Refnement 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 specifcation bugs
•
Example: network protocols
Part 2: During the execution
➢
The OS as a shield
•
Protecting the memory
•
Confned execution context
•
Protecting the kernel system calls (Syslog)
•
Protecting the fles (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 overfow 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 overfow
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
Confned 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