1. CSCE 548 Secure Software Development Information Leakage + Failing to Handle Errors

2. CSCE 548 - Farkas2 Reading This lecture: Howard et al., 19 deadly sins: Chapters 6, 13, 12, 11 Howard et al., 24 deadly sins: Chapters 11, 12, 17, 19

3. Identification Establishes the identity of an individual/system/ap- plication/etc. Proof of identity: password, driver’s license, Id card, etc. CSCE 522 - Farkas3

4. 4 Authentication Allows an entity (a user or a system) to prove its identity within a context, e.g., computer system Typically, the entity whose identity is verified reveals knowledge of some secret S to the verifier Strong authentication: the entity reveals knowledge of S to the verifier without revealing S to the verifier

5. CSCE 522 - Farkas5 Vulnerabilities of Passwords Inherent vulnerabilities – Easy to guess or snoop – No control on sharing Practical vulnerabilities – Visible if unencrypted in distributed and network environment – Susceptible for replay attacks if encrypted naively Password advantage – Easy to modify compromised password.

6. Digital Certificates Most common digital certificate: X.509 Initially issued in 1988 Rely on PKI and hierarchy of certificate authorities Certificate Authority: issue and revoke digital certificates, accepts user notifications, publishes revocation list CSCE 522 - Farkas6

7. Problem with X.509 Large file Long duration  needs validation of certificate for revocation Why are digital certificates revoked? – Exposure of private key – Incorrect/unauthorized issuance – Termination of assignment CSCE 522 - Farkas7

8. Return to Multiple Authentication CSCE 522 - Farkas8 I am Ann. Here is my X.509 System 1 System 3 System 2 I am Ann. Here is my X.509 I am Ann. Here is my X.509 CA Verify Certificate

9. Single Sign On CSCE 522 - Farkas9 I am Ann. Here is my X.509. Give me a locally verifiable token. System 1 System 3 System 2 I am Ann. Here is my SAML token I am Ann. Here is my SAML token SAML token CA Verify Certificate

10. CSCE 548 - Farkas10 Information Protection During transit During use During storage

11. CSCE 548 - Farkas11 Access Control Access control: ensures that all direct accesses to object are authorized Protects against accidental and malicious threats by regulating the reading, writing and execution of data and programs Need: – Proper user identification and authentication – Information specifying the access rights is protected form modification

12. CSCE 548 - Farkas12 Implementation Access Control List (column) File 1File 2Joe:Read Joe:WriteSam:Read Joe:OwnSam:Write Sam:Own Capability List (row) Joe: File 1/Read, File 1/Write, File 1/Own, File 2/Read Sam: File 2/Read, File 2/Write, File 2/Own Access Control Triples SubjectAccessObject JoeReadFile 1 JoeWriteFile 1 JoeOwnFile 1 JoeReadFile 2 SamReadFile 2 SamWrite File 2 SamOwnFile 2 (ACL)

13. CSCE 548 - Farkas13 Problem Areas Too much access – Not following least privilege Security violations – Deny access – unavailability – World readable – information disclosure – Write for everyone – incorrect execution, denial of service, taking over the system

14. CSCE 548 - Farkas14 Recommendation Use the operating system’s security technologies Keep secrets out of harm’s way Use security technology (access control support, encryption, etc.) properly Scrub the memory securely once finished with secret data

15. CSCE 548 - Farkas15 Weak Access Control Set access control and grants write access to low privileged user Creates an object without setting access control and creates object in a place writable by low- privileged user Writes configuration information into a shared area Writes sensitive information into a shared area

16. CSCE 548 - Farkas16 Information Leakage By accident By intention

17. CSCE 548 - Farkas17 Communication Channels Overt Channel: designed into a system and documented in the user's manual – Information leakage: designers and developers DO NOT understand security needs of the application Covert Channel: not documented. Covert channels may be deliberately inserted into a system, but most such channels are accidents of the system design. – Information leakage: slow information flow to unauthorized recipient

18. CSCE 548 - Farkas18 Information Flow Direct Flow: – Bell-LaPadula example Indirect flow: – Covert channel – Inference channel TS-subject S-object read info- flow TS-object S-subject write info- flow

19. CSCE 548 - Farkas19 Non-Interference High-security data does not influence lower security data How to guarantee it?

20. CSCE 548 - Farkas20 Covert Channel Timing Channel: based on system times Storage channel: not time related communication Can be turned into each other

21. CSCE 548 - Farkas21 Covert Channel Need: – Two active participants and encoding schema OR – Access to the system and knowledge about the system Example: sender modulates the CPU utilization level with the data stream to be transmitted Sender: repeat get a bit to send if the bit is 1 wait one second (don't use CPU time) else busy wait one second (use CPU time) endif until done

22. CSCE 548 - Farkas22 Covert Channels Problems: – Noise – Need sophisticated synchronization Protection (user state, system state) – Removal – Slow down – Audit

23. CSCE 548 - Farkas23 Cryptographic Timing Attack How long does it take to perform encryption – Table look ups – Non-constant time – Partial guesses  faster performance Measure the duration between messages, where message content depends on secret data

24. CSCE 548 - Farkas24 Inference Channels Statistical Database Inferences General Purpose Database Inferences

25. CSCE 548 - Farkas25 Statistical Databases Goal: provide aggregate information about groups of individuals – E.g., average grade point of students Security risk: specific information about a particular individual – E.g., grade point of student John Smith Meta-data: – Working knowledge about the attributes – Supplementary knowledge (not stored in database)

26. CSCE 548 - Farkas26 Types of Statistics Macro-statistics: collections of related statistics presented in 2-dimensional tables Micro-statistics: Individual data records used for statistics after identifying information is removed Sex\Year19971998Sum Female415 Male 6 1319 Sum101424 SexCourseGPAYear FCSCE 5903.52000 M CSCE 590 3.02000 FCSCE 7904.02001

27. CSCE 548 - Farkas27 Statistical Compromise Exact compromise: find exact value of an attribute of an individual (e.g., John Smith’s GPA is 3.8) Partial compromise: find an estimate of an attribute value corresponding to an individual (e.g., John Smith’s GPA is between 3.5 and 4.0)

28. CSCE 548 - Farkas28 Inferences in General-Purpose Databases Queries based on sensitive data Inference via database constraints Inferences via updates

29. CSCE 548 - Farkas29 Queries based on sensitive data Sensitive information is used in selection condition but not returned to the user. Example: Salary: secret, Name: public  Name  Salary=$25,000 Protection: apply query of database views at different security levels

30. CSCE 548 - Farkas30 Database Constraints Integrity constraints Database dependencies Key integrity

31. CSCE 548 - Farkas31 Integrity Constraints C=A+B A=public, C=public, and B=secret B can be calculated from A and C, i.e., secret information can be calculated from public data

32. CSCE 548 - Farkas32 Database Dependencies Metadata: Functional dependencies Multi-valued dependencies Join dependencies etc.

33. CSCE 548 - Farkas33 Functional Dependency FD: A  B, that is for any two tuples in the relation, if they have the same value for A, they must have the same value for B. Example: FD: Rank  Salary Secret information: Name and Salary together – Query1: Name and Rank – Query2: Rank and Salary – Combine answers for query1 and 2 to reveal Name and Salary together

34. CSCE 548 - Farkas34 Key integrity Every tuple in the relation have a unique key Users at different levels, see different versions of the database Users might attempt to update data that is not visible for them

35. CSCE 548 - Farkas35 Example Name (key)SalaryAddress Black P38,000 PColumbia S Red S42,000 SIrmo S Secret View Name (key)SalaryAddress Black P38,000 PNull P Public View

36. CSCE 548 - Farkas36 Updates Public User: Name (key)SalaryAddress Black P38,000 PNull P 1.Update Black’s address to Orlando 2.Add new tuple: (Red, 22,000, Manassas) If Refuse update: covert channel Allow update: Overwrite high data – may be incorrect Create new tuple – which data it correct (polyinstantiation) – violate key constraints

37. CSCE 548 - Farkas37 Updates Name (key)SalaryAddress Black P38,000 PColumbia S Red S42,000 SIrmo S Secret user: 1.Update Black’s salary to 45,000 If Refuse update: denial of service Allow update: Overwrite low data – covert channel Create new tuple – which data it correct (polyinstantiation) – violate key constraints

38. CSCE 548 - Farkas38 Inference Problem No general technique is available to solve the problem Need assurance of protection Hard to incorporate outside knowledge

39. Failing to Handle Errors CSCE 548 - Farkas39

40. CSCE 548 - Farkas40 Failing to Handle Errors Affected languages: – Any language that uses function error return values, e.g., PHP, C, C++, etc. – Any language that relies on exceptions, e.g., C#, Java, etc. Consequences: – Yielding too much information – Ignoring errors – Misinterpreting errors – Using useless error values – Handling the wrong exceptions – Handling all exceptions

41. CSCE 548 - Farkas41 Yielding Too Much Information Error message carries information that can be misused by the attacker Avoid: do not tell the user why his input failed Problem: reduces usability

42. CSCE 548 - Farkas42 Ignoring Errors Error return values: indicate a failure condition, enabling the code to react accordingly How serious the error is? – Return value rarely checked, e.g., printf – Return value must be checked, e.g., Windows impersonation functions  if failed, the thread still has the processes identity Exception handling – Catch exceptions at compile time – Some exceptions are not required to be caught, e.g., NullPointerException  miss logic error Handling exceptions and errors

43. CSCE 548 - Farkas43 Misinterpreting Errors and Useless Error Values Functions with special errors – E.g., recv(): Successful completion: # of bytes received No msg. and orderly shut down: 0 Error: -1 No error value – E.g., strncpy: Returns a pointer to the destination buffer, regardless of the state of the copy Buffer overrun?

44. CSCE 548 - Farkas44 Handling the Wrong Exceptions, Handling All Exceptions Which exception is going to be thrown? – Standard, expected exceptions – Unexpected exceptions  program terminates because the exception is not caught All exceptions handled: code may not be able to handle the exception or mask the error – Error may resurface at a later stage  hard to detect

45. CSCE 548 - Farkas45 Detecting Error Handling Flaws Code review – Look for key words – See page 79 Some tools are available Redemption steps: – Handle the appropriate exceptions in your code – Don’t handle ALL exceptions – Check return values, in particular Security related functions Functions that changes user setting or machine-wide setting

46. CSCE 548 - Farkas46 Design Patterns Capture security effective techniques that should be replicated Distill and document these techniques – design patters CMU.SEI 2009 security design patterns – Architectural – Design-level – Implementation0level

47. Each Pattern Intent Also known as Example Motivation Applicability structure Participants consequence Implementation Sample code Example resolved Known uses CSCE 548 - Farkas47

48. Example SOA Message screening pattern, from http://www.soapatterns.org/message_screening.php http://www.soapatterns.org/message_screening.php Problem: An attacker can transmit messages with malicious or malformed content to a service, resulting in undesirable behavior. Solution The service is equipped or supplemented with special screening routines that assume that all input data is harmful until proven otherwise. CSCE 548 - Farkas48

49. Example cont. Application: When a service receives a message, it makes a number of checks to screen message content for harmful data. Impacts: Extra runtime processing is required with each message exchange, and the screening logic requires additional, specialized routines to process binary message content, such as attachments. It may also not be possible to check for all possible forms of harmful content. CSCE 548 - Farkas49

50. Example cont. CSCE 548 - Farkas50

51. Next Class Buffer overflow and SQL Injection CSCE 548 - Farkas51