secure operating systems john mitchell cs 155may 3, 2005
Post on 21-Dec-2015
227 views
TRANSCRIPT
![Page 1: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/1.jpg)
Secure Operating Systems
John Mitchell
CS 155 May 3, 2005
![Page 2: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/2.jpg)
Last Lecture This lecture
Access Control Concepts• Matrix, ACL, Capabilities• Multi-level security (MLS)
OS Mechanisms• Multics
– Ring structure
• Amoeba– Distributed, capabilities
• Unix– File system, Setuid
• Windows– File system, Tokens, EFS
• SE Linux– Role-based, Domain type enforcement
Secure OS• Stronger mechanisms• Some limitations
Assurance• Orange Book, TCSEC• Common Criteria• Windows 2000
certification
Cryptographic File Systems
Embedded OS• Some issues in Symbian
security
Software Patches
![Page 3: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/3.jpg)
What makes a “secure” OS?
Extra security features (compared to last lecture)• Stronger authentication mechanisms
– Example: require token + password
• More security policy options– Example: only let users read file f for purpose p
• Logging and other features More secure implementation
• Apply secure design and coding principles• Assurance and certification
– Code audit or formal verification
• Maintenance procedures– Apply patches, etc.
![Page 4: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/4.jpg)
Sample Features of “Trusted OS”
Mandatory access control• MAC not under user control, precedence over DAC
Object reuse protection• Write over old data when file space is allocated
Complete mediation• Prevent any access that circumvents monitor
Audit• Log security-related events and check logs
Intrusion detection• Anomaly detection
– Learn normal activity, Report abnormal actions
• Attack detection– Recognize patterns associated with known attacks
![Page 5: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/5.jpg)
DAC and MAC
Discretionary Access Control• Restrict a subject's access to an object
– Generally: limit a user's access to a file– Owner of file controls other users' accesses
Mandatory Access Control• Needed when security policy dictates that:
– protection decisions must not be left to object owner
– system enforces a security policy over the wishes or intentions of the object owner
Jack, Kack, Lack, Mack, Nack, Ouack, Pack and Quack
![Page 6: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/6.jpg)
DAC vs MAC
DAC• Object owner has full
power• Complete trust in
users• Decisions are based
only on user id and object ownerships
• Impossible to control information flow
MAC• Object owner CAN
have some power• Only trust in
administrators• Objects and tasks
themselves can have ids
• Makes information flow control possible
![Page 7: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/7.jpg)
Information flow
High
Low
High
Low
inputs
inputs
outputs
outputs
Process
![Page 8: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/8.jpg)
Controlling information flow
MAC policy• Information from one object may only flow to an
object at the same or at a higher security level
Conservative approach• Information flow takes place when an object
changes its state or when a new object is created
Implementation as access policy• If a process reads a file at one security level, it
cannot create or write a file at a lower level• This is not a DAC policy, not an ACL policy
![Page 9: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/9.jpg)
SELinux
Security-enhanced Linux system (NSA)• Enforce separation of information based on
confidentiality and integrity requirements • Mandatory access control incorporated into the major
subsystems of the kernel– Limit tampering and bypassing of application security
mechanisms – Confine damage caused by malicious applications
Why Linux? Open source• Already subject to public review• NSA can review source, modify and extend
– Assurance methods later in lecture …
http://www.nsa.gov/selinux/
![Page 10: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/10.jpg)
Problem: crypto module
Signing
key
Input Output
Signing algorithm
Actual hope: low security output does not reveal high security input
![Page 11: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/11.jpg)
Information flow analysis
First guess• Mark expressions as high or low
– Some resemblance to Perl tainting
• Check assignment for high value in low location
But consider if (xhigh > 0) ylow = 0;
else ylow = 1;
State of the art• Much research on type systems and program
analysis to determine software information flow• Still not ready for prime time
![Page 12: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/12.jpg)
Covert Channels
Butler Lampson• Difficulty achieving confinement (paper on
web)
• Communicate by using CPU, locking/unlocking file, sending/delaying msg, …
Gustavus Simmons• Cryptographic techniques make it impossible
to detect presence of a covert channel
![Page 13: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/13.jpg)
Example
The Two-Server Trojan Horse:• Device P can chose from two Key Servers• P is expected to choose randomly, to balance load• But reveals key one bit at a time
Observations• Information flow easily detected by noninterference
analysis of the algorithm• More subtle if choice based on random seed known to
external attacker
P S1
S2
key
[McLean]
Also: DNS lookup, SSL nonce, …
![Page 14: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/14.jpg)
Sample Features of Trusted OS
Mandatory access control• MAC not under user control, precedence over DAC
Object reuse protection• Write over old data when file space is allocated
Complete mediation• Prevent any access that circumvents monitor
Audit• Log security-related events and check logs
Intrusion detection• Anomaly detection
– Learn normal activity, Report abnormal actions
• Attack detection– Recognize patterns associated with known attacks
![Page 15: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/15.jpg)
Interesting risk: data lifetime
Recent work• Shredding Your Garbage: Reducing Data Lifetime
Through Secure Deallocation by Jim Chow, Ben Pfaff, Tal Garfinkel, Mendel
Rosenblum
Example• User types password into web form• Web server reads password• Where does this go in memory?
– Many copies, on stack and heap– Optimizing compilers may remove “dead”
assignment/memcopy– Presents interesting security risk
![Page 16: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/16.jpg)
Sample Features of Trusted OS
Mandatory access control• MAC not under user control, precedence over DAC
Object reuse protection• Write over old data when file space is allocated
Complete mediation• Prevent any access that circumvents monitor
Audit• Log security-related events and check logs
Intrusion detection (cover in another lecture)
• Anomaly detection– Learn normal activity, Report abnormal actions
• Attack detection– Recognize patterns associated with known attacks
![Page 17: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/17.jpg)
Kernelized Design
Trusted Computing Base• Hardware and software for
enforcing security rules
Reference monitor• Part of TCB • All system calls go
through reference monitor for security checking
• Most OS not designed this way
User space
Kernel space
User proces
s
OS kernel
TCB
Reference monitor
![Page 18: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/18.jpg)
Audit
Log security-related events Protect audit log
• Write to write-once non-volatile medium
Audit logs can become huge• Manage size by following policy
– Storage becomes more feasible– Analysis more feasible since entries more meaningful
• Example policies– Audit only first, last access by process to a file– Do not record routine, expected events
• E.g., starting one process always loads …
![Page 19: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/19.jpg)
Assurance methods
Testing• Can demonstrate existence of flaw, not
absence
Formal verification• Time-consuming, painstaking process
“Validation”• Requirements checking• Design and code reviews
– Sit around table, drink lots of coffee, …
• Module and system testing
![Page 20: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/20.jpg)
Rainbow Series
DoD Trusted Computer Sys Evaluation Criteria (Orange Book) Audit in Trusted Systems (Tan Book) Configuration Management in Trusted Systems (Amber Book)Trusted Distribution in Trusted Systems (Dark Lavender Book) Security Modeling in Trusted Systems (Aqua Book) Formal Verification Systems (Purple Book) Covert Channel Analysis of Trusted Systems (Light Pink Book)… many more
http://www.radium.ncsc.mil/tpep/library/rainbow/index.html
![Page 21: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/21.jpg)
Orange Book Criteria (TCSEC)
Level D• No security requirements
Level C For environments with cooperating users• C1 – protected mode OS, authenticated login,
DAC, security testing and documentation (Unix)
• C2 – DAC to level of individual user, object initialization, auditing (Windows NT 4.0)
Level B, A• All users and objects must be assigned a security
label (classified, unclassified, etc.)• System must enforce Bell-LaPadula model
![Page 22: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/22.jpg)
Levels B, A (continued)
Level B• B1 – classification and Bell-LaPadula• B2 – system designed in top-down modular way,
must be possible to verify, covert channels must be analyzed
• B3 – ACLs with users and groups, formal TCB must be presented, adequate security auditing, secure crash recovery
Level A1• Formal proof of protection system, formal proof
that model is correct, demonstration that impl conforms to model, formal covert channel analysis
![Page 23: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/23.jpg)
Common Criteria
Three parts• CC Documents
– Protection profiles: requirements for category of systems• Functional requirements• Assurance requirements
• CC Evaluation Methodology• National Schemes (local ways of doing evaluation)
Replaces TCSEC, endorsed by 14 countries• CC adopted 1998 • Last TCSEC evaluation completed 2000
http://www.commoncriteria.org/
![Page 24: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/24.jpg)
Protection Profiles
Requirements for categories of systems• Subject to review and certified
Example: Controlled Access PP (CAPP_V1.d)• Security functional requirements
– Authentication, User Data Protection, Prevent Audit Loss
• Security assurance requirements– Security testing, Admin guidance, Life-cycle support, …
• Assumes non-hostile and well-managed users• Does not consider malicious system developers
![Page 25: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/25.jpg)
Evaluation Assurance Levels 1 – 4
EAL 1: Functionally Tested• Review of functional and interface specifications• Some independent testing
EAL 2: Structurally Tested• Analysis of security functions, incl high-level design• Independent testing, review of developer testing
EAL 3: Methodically Tested and Checked• Development environment controls; config mgmt
EAL 4: Methodically Designed, Tested, Reviewed• Informal spec of security policy, Independent testing
![Page 26: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/26.jpg)
Evaluation Assurance Levels 5 – 7
EAL 5: Semiformally Designed and Tested• Formal model, modular design• Vulnerability search, covert channel analysis
EAL 6: Semiformally Verified Design and Tested• Structured development process
EAL 7: Formally Verified Design and Tested• Formal presentation of functional specification• Product or system design must be simple• Independent confirmation of developer tests
![Page 27: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/27.jpg)
Example: Windows 2000, EAL 4+
Evaluation performed by SAIC Used “Controlled Access Protection Profile” Level EAL 4 + Flaw Remediation
• “EAL 4 … represents the highest level at which products not built specifically to meet the requirements of EAL 5-7 ought to be evaluated.”
(EAL 5-7 requires more stringent design and development procedures …)
• Flaw Remediation
Evaluation based on specific configurations• Produced configuration guide that may be useful
![Page 28: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/28.jpg)
![Page 29: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/29.jpg)
Is Windows is “Secure”?
Good things• Design goals include security goals• Independent review, configuration guidelines
But …• “Secure” is a complex concept
– What properties protected against what attacks?
• Typical installation includes more than just OS– Many problems arise from applications, device drivers– Windows driver certification program
• Security depends on installation as well as system
![Page 30: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/30.jpg)
Secure attention sequence (SAS)
CTRL+ALT+DEL• “… can be read only by Windows, ensuring that the
information in the ensuing logon dialog box can be read only by Windows. This can prevent rogue programs from gaining access to the computer.”
How does this work?• Winlogon service responds to SAS • DLL called GINA (for Graphical Identification 'n'
Authentication) implemented in msgina.dll gathers and marshals information provided by the user and sends it to the Local Security Authority (LSA) for verification
• The SAS provides a level of protection against Trojan horse login prompts, but not against driver level attacks.
![Page 31: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/31.jpg)
Encrypted File Systems (EFS, CFS)
Store files in encrypted form• Key management: user’s key decrypts file• Useful protection if someone steals disk
Windows – EFS• User marks a file for encryption• Unique file encryption key is created• Key is encrypted, can be stored on smart card
Unix – CFS [Matt Blaze]• Transparent use• Local NFS server running on "loopback" interface • Key protected by passphrase
![Page 32: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/32.jpg)
Q: Why use crypto file system?
General security questions• What properties are provided?• Against what form of attack?
Crypto file system• What properties?
– Secrecy, integrity, authenticity, … ?
• Against what kinds of attack?– Someone steals your laptop?– Someone steals your removable disk?– Someone has network access to shared file system?
Depends on how file system configured and used
![Page 33: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/33.jpg)
Encrypted file systems Several possible designs
• Block based systems• Disk based systems• Network loopback based systems• Stackable file systems • Application based encryption
Some references• A cryptographic file system for unix
– Matt Blaze• Cryptographic File Systems Performance
– Charles Wright, Jay Dave and Erez Zadok• Cryptoloop HowTo
– Dennis Kaledin et. al• Ncryptfs: A secure and convenient cryptographic file system
– Wright et. al
![Page 34: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/34.jpg)
Block Based
Encrypt one disk block at a time• Not dependent on underlying file system• Can write to raw device or preallocated file
![Page 35: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/35.jpg)
Sample block-based implementation
Cryptoloop• Uses Linux loopback device driver, CryptoAPI
– Linux kernel CryptoAPI exports an interface to encryption functions and hash functions
• Can write to a raw device or to a preallocated file – Preallocated file effectively cuts buffer cache in half
![Page 36: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/36.jpg)
Other block-based file systems CGD (Cyptographic disk driver)
• For NetBSD• raw device only
BestCrypt• Commercial product for Linux and windows• preallocated file for storage
vncrypt• For FreeBSD: uses the vn device driver• preallocated file for storage
vnd• For OpenBSD: uses the Vnode disk driver (vnd)• preallocated file for storage
![Page 37: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/37.jpg)
Disk Based
Encrypt data at the file system level
![Page 38: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/38.jpg)
Disk Based
EFS (Encryption File System)• Extension to NTFS based on NT kernel. • Uses windows access control and authentication
libraries though located in the kernel, its tightly coupled with user space dlls to do encryption and user authentication.
• Encryption keys are stored on the disk, encrypted with user password
StegFS • A file system that employs encryption and
steganography• Inspection of system will not reveal content or extent
of hidden data• uses modified ext2 kernel driver• Very slow and hence impractical
![Page 39: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/39.jpg)
Network Based
CFS• User level crypto NFS server
– Performance hampered by many context switches and data copies between user and kernel space
• Data appears in user space in cleartext
![Page 40: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/40.jpg)
Network Based
TCFS• modified kernel mode nfs client• works with normal nfs server• keys are stored on the filesystem
![Page 41: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/41.jpg)
Stackable Systems
Ncryptfs• Can operate on top of any file system.
![Page 42: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/42.jpg)
Application based encryption
Applications like pgp, SafeHouse allow users to encrypt/decrypt files
File may be in cleartext on the disk while the user is editing and saving it
![Page 43: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/43.jpg)
Encrypted file system
Complete file system encryption is feasible in real time• Crypto operations are not a big bottleneck• Performance study: with single processor,
I/O is limiting factor• Caching plays a big role in performance of
encrypted systems
![Page 44: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/44.jpg)
Embedded operating systems
Symbian History• Psion released EPOC32 in 1996
– based on 1989 EPOC OS– EPOC32 was designed with OO in C++
• Symbian Ltd. formed in 1998– Ericsson, Nokia, Motorola and Psion– EPOC renamed to Symbian OS– Currently ~30 phones with Symbian,15 licensees
• Current ownership Nokia 47.5% Panasonic 10.5% Ericsson 15.6% Siemens 8.4% SonyEricsson 13.1% Samsung 4.5%
See: Symbian phone security, Job de Haas, BlackHat, Amsterdam 2005
![Page 45: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/45.jpg)
Symbian UI
Two main version Series60 UIQ
![Page 46: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/46.jpg)
Architecture
Multitasking, preemptive kernel MMU protection of kernel and process spaces Strong Client–Server architecture Plug-in patterns Filesystem in ROM, Flash, RAM and on SD-card
![Page 47: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/47.jpg)
Symbian Development
Emulator on x86 runs most of native code base• Compiled to x86 (so not running ARM cpu)• Emulator is one windows process
Limited support for on-target debugging• It does not work on all devices• Uses a gdb stub• Metrowerks provides MetroTRK• Future: v9 will move to ARM Real View (RVCT)
and the EABI standard
![Page 48: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/48.jpg)
Mobile phone risks Toll fraud:
• Auto dialers.• High cost SMS/MMS.• Phone Proxy
Loss or theft:• Data loss.• Data compromise.• Loss of Identity (caller ID)
Availability:• SPAM.• Destruction of the device
(flash)• Destruction of data.
Risks induced by usage:• Mobile banking.• Confidential e-mail,
documents.• Device present at confidential
meetings: snooping
Attack vectors• Executables• Bluetooth• GPRS / GSM• OTA• IrDa• Browser• SMS / MMS• SD card• WAP• E-mail• Too many entry points to list
all
![Page 49: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/49.jpg)
Symbian security features Crypto:
• Algorithms• Certificate framework• Protocols: HTTPS, WTLS, …
Symbian signed:• Public key signatures on
applications• Root CA’s in ROM
Separation• Kernel vs. user space;• process space• Secured ‘wallet’ storage
Access controls• SIM PIN, device security code• Bluetooth pairing
Artificial Limitations / patches• Prevent loading device
drivers in the kernel (Nokia).• Disallow overriding of ROM
based plug-ins
Limitations• No concept of roles or users.• No access controls in the file
system.• No user confirmation
needed for access by applications.
• User view on device is limited: partial filesystem, selected processes.
• Majority of interesting applications is unsigned.
Are attacks prevented?• Fraud: user should not
accept unsigned apps• Loss/theft: In practice,
little protection• Availability: any
application can render phone unusable (skulls trojan).
![Page 50: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/50.jpg)
Symbian attacks
What goes wrong?• All known attacks need user confirmation.
Often more than once.• People loose a lot devices
Skulls Trojan:• Theme that replaces all icons and cannot be de-
installed
Caribe:• Installs itself as a ‘Recognizer’ to get activated at
boot time and starts broadcasting itself over Bluetooth
![Page 51: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/51.jpg)
Example vulnerability
February 23, 2005 notice on Nokia site:
Proposed workaround
![Page 52: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/52.jpg)
User confirmation
This is what appears on the screen when an untrusted application is loaded:
![Page 53: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/53.jpg)
Installing patches
Many attacks occur after patch released• Applies to OS and applications
Case study: patches for Open SSL• Recall: Secure Socket Layer (SSL) protocol
provides authentication and confidentiality between two communicating applications
• OpenSSL is a open source implementation– Remote buffer overflow in OpenSSL server
• Case study by Eric Rescorla, RTFM, Inc.
![Page 54: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/54.jpg)
Server Side SSLv2 Vulnerability
During a handshake with the server, the client can send a overly long CLIENT-MASTER-KEY for SSLv2.
Resulting in heap overflow.
Client Server
challenge, cipher_specs
connection-id, server_certificate, cipher_specs{master_key} server_public_key
verification and finalization
“No Session Identifier” Handshake for Remote Connections
![Page 55: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/55.jpg)
Server Side SSLv2 Vulnerability
char MSG-CLIENT-MASTER-KEYchar CIPHER-KIND[3]char CLEAR-KEY-LENGTH-MSBchar CLEAR-KEY-LENGTH-LSBchar ENCRYPTED-KEY-LENGTH-MSBchar ENCRYPTED-KEY-LENGTH-LSBchar KEY-ARG-LENGTH-MSBchar KEY-ARG-LENGTH-LSBchar CLEAR-KEY-DATA[MSB<<8|LSB]char ENCRYPTED-KEY-DATA[MSB<<8|LSB]char KEY-ARG-DATA[MSB<<8|LSB]
• All block ciphers used in OpenSSL use 8 byte key • OpenSSL allocates fixed 8-byte buffer for KEY-ARG-DATA• Specifying a larger key length with KEY-ARG-DATA overflow the heap• OpenSSL uses a lot of function pointers that heap overflow can exploit
Structure of CLIENT-MASTER-KEY message
![Page 56: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/56.jpg)
Ethical Probing for Fixes
Patched servers close connection if key length too big Unpatched servers accept KEY-ARG-LENGTH > 8
• Rescorla set KEY-ARG-LENGTH = 9• Overwrites next field in the heap, master_key_length (MKL)• MKL not used anywhere else, so no real damage
struct CLIENT MASTER KEY MKL
struct CLIENT MASTER KEY
![Page 57: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/57.jpg)
Timeline
30th July 2002• Initial announcement of vulnerability• OpenSSL 0.9.6e available for download (bug fixed)• Patches for other versions released• Major OS vendors (Debian, Trustix, Engarde, Gentoo) announce• Posting of vulnerability to SlashDot
31st July 2002• FreeBSD announces
2nd August 2002• Apple announces. NetBSD announces
9th August 2002• OpenSSL 0.9.6g released
13th September 2002• Slapper worm released (More than 60% still vulnerable)
July August September
30 31 2 9 13
![Page 58: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/58.jpg)
Patches and upgrades over 30 days
23% of the servers are fixed within first week of announcement More than 60% of servers still vulnerable when the Slapper worm
which exploited the bug was released 6 weeks later
% vulnerable
days
Vulnerable Servers over a 30 Days Period
Graphs ends at
60% vulnerable
![Page 59: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/59.jpg)
Second wave after worm exploit
Some administrators only patch/upgrade when exploit shows up
% vulnerable
days
Vulnerable Servers after Slapper was releasedGraphs starts at
60% vulnerable
Summary 1/3 upgrade when advisory released 1/3 upgrade when exploit released 1/3 do not bother
![Page 60: Secure Operating Systems John Mitchell CS 155May 3, 2005](https://reader034.vdocuments.us/reader034/viewer/2022042511/56649d6d5503460f94a4db06/html5/thumbnails/60.jpg)
OS Security lectures
Access Control Concepts• Matrix, ACL, Capabilities• Multi-level security (MLS)
OS Mechanisms• Multics
– Ring structure
• Amoeba– Distributed, capabilities
• Unix– File system, Setuid
• Windows– File system, Tokens, EFS
• SE Linux– Role-based, Domain type enforcement
Secure OS• Stronger mechanisms• Some limitations
Assurance• Orange Book, TCSEC• Common Criteria• Windows 2000
certification
Cryptographic File Systems
Embedded OS• Some issues in Symbian
security
Software Patches