MaLwArE cS 510

1. MaLwArEcS 510 Paper Title : Practical Proactive Integrity Preservation: A Basis for Malware Defense Presenter : Abdulwahab

2. information flow based approaches • It can provide positive assurance about overall system integrity, hence can defend against sophisticated malware. • No Much success in applying it to desktop systems running modern COST operating systems. • Due to: • A strict application of information flow policy can break existing applications & OS services. • Difficulty of policy development.

3. Malware defenses rely on reactive approaches : • Signature-based scanning. • Behavior monitoring. • File integrity monitoring. • Problem : • Attackers can easily modify the structure & behavior of their malware to evade detection. • They may also subvert system integrity monitoring tools using rootkit-like techniques.

4. Therefore, It is necessary to develop proactive techniques that can stop malware before it damages the system integrity. Sandboxing.

5. Sandboxing • It is commonly deployed proactive defense against untrusted software. • It restricts the set of resources that can be written by an untrusted process. • It limits communication with other processes on the system.

6. Sandboxing • However : • Techniques that regulate write-access without restricting read-access are not sufficient. • They do not satisfactorily address indirect attacks, where a benign application ends up consuming malware outputs stored in persistent storage. • For instance: • malware may modify the following types of files used by a benign application: • System libraries, configuration files or scripts. • User-specific customization files and scripts. • Data files.

7. The Approach : PPI • Called PPI [Practical Proactive Integrity protection ] • It identifies : • subset of objects [ integrity critical ] • Set of [untrusted] object. • “ Authors assume that [system integrity] is preserved as long as [untrusted objects] are prevented from influencing the contents of [integrity-critical objects] • either • Directly : by copying of an untrusted object over an integrity-critical object • Indirectly : through intermediate files

8. Goals of Approach • Provide positive assurances about system integrity • Eectively block rootkits and most other malware. • Be easy to use: for end-users , sys-administrators • Usability encompasses : • Preserve availability of benign applications. • Minimize administrator effort. • Eliminate user prompts. • Reduce reliance on trusted applications

9. Salient Features: • Flexible decomposition of high-level policies into low-level policies. • Automated analysis for generatingenforeceable policies. • A flexible enforcement framework. • Mechanisms for limiting trust.

10. Policy Framework *Trust and Integrity Levels - They used just two integrity levels : . High integrity. . Low integrity. - Integrity labels are associated with all objects in the system files – devices – communication channels. - A subset of high-integrity objects need to be identified as integrity-critical, which provide the basis for defining system integrity: Def. (System Integrity) : they say that system integrity is preserved as long as all integrity-critical objects have high integrity labels. * The set of integrity-critical objects is externally specified by : - A system administrator. - An OS distribution developer.

11. Policy Framework • When referring to applications : • They use the term [ trust level ] instead of [ integrity level ]. • Benignapplications: are those that are known to be benign, and may include applications that are obtained from a trusted source. • Files that constitute benign applications will have high integrity. • benign applications will remain trustworthy as long as they never exposed to low-integrity. • A subset of benign applications may be designated as trusted.

12. Policy Framework • Untrustedapplications : are those that are obtained from untrusted source. • E.g : downloaded from an unknown website • arriving via email from unauthenticated sources. An unspecified subset of these applications may be malicious.

13. Policy Framework • Integrity Labels Versus Policies • They distinguish between integrity labels and policies. • An integrity Label: on a file simply indicates whether its content is trustworthy, but does not dictate whether trustworthiness must be preserved, say, by preventing low-integrity subjects from writing to that file.

14. Policy Framework • A policy: indicates whether a certain read or write access should be permitted. • The benefit of that separation is flexibility in developing polices that preserve system integrity without unduly impacting usability.

15. Automating policy Development • Authors envision policy development to be undertaken by a security expert. • The goal : to minimize the effort needed on the part of this expert. • The input to the policy generation algorithm consists of: • Software package information, including package contents and dependencies • A list of untrusted packages and/or files • The list of integrity-critical objects • A log file • that records resource accesses observed during normal operation on an unprotected system.

16. Computing Dependencies, Contexts andLabels • Deriving Initial Object Labels. • Initial object labels are derived using the following steps: • Mark all packages that depend on untrustedpackages as untrusted. • Label all objects that belong to untrustedpackages with low-integrity. • Label any object that was written by an untrusted subject with low integrity. • Label all other objects as having high integrity.

17. Policy Generation • The policy generation algorithm consists of four phases: 1.Identification of objects whose integrity needs to be preserved. 2. Resolution of conflicting accesses. 3. Log simulation and policy refinement. 4. Policy generation for new applications.

18. 1st Phase • 1. Initialize: • For every package P such that an integrity-critical package depends on it, add P to the set of integrity-critical packages. • For every object that belongs to an integrity-critical or object that is explicitly labeled as integrity-critical, mark it as [preserve high]. • For every program P that is ever executed in the system context, mark P as [preserve high]. • 2. Propagate from object to subject. • If a program P writes as object Q that is marked [preserve high ], then mark P as [preserve high].

19. 1st Phase • 3. Propagate from subject to object. • If a program P read or executes as object Q, then mark Q as [ preserve high ] . • 4. Repeat the previous two steps until a fixid point is reached.

20. 2nd Phase : • This phase identifies which of the policy choices should be applied to each conflicting access involving (subject , object, access) • Deny policy: • For every object labeled preserve high, the default policy is • To permit reads by any subject, • But deny writes by low-integrity subjects • For every object labeled with low-integrity the default policy is : • To permit reads by low-integrity subjects, • But deny reads by high-integrity subjects • Exceptions to these defaults are made as decribed in coming slides depending upon the program executed by a subject, and its trust level

21. 2nd Phase • Downgrade subject policy: • A high-integrity subject P running in context c will be permitted to downgrade itself to low-integrity if there are runs in the log file where Pc c read a low integrity file, and did not write any high integrity objects subsequently. • Trust policy: • Each subject P that reads a low-integrity object and writes to an object marked preserve-high is a candidate for the “trust" policy.

22. 2nd Phase • Downgrade object policy: • Any object that is not marked as preserve-high can be downgraded when it is overwritten by a low-integrity subject. • Redirect policy: • A redirect policy is applied to the combination (P,O,write) if : • A - O is marked preserve high. • B - P reads O in almost every run. • C - P writes O in a non-negligible fraction of runs.

23. 3rd Phase : • A problem in 2nd phase : • did not take into account that file labels will change as the operations contained in the log file are performed. • Solution : • They “simulate" the accesses found in the log. • They track the integrity levels of objects and subjects during this simulation,

24. 3rd phase • They report all accesses that cause a violation of the policy generated in the previous step. • The violation reports are aggregated based on the subject (or object). • They are sorted in decreasing order of the number of occurrences. • Based on that conflict report: • The policy developer may refine the set of trusted, benign, or untrusted programs.

25. 4th Phase: • New files get created in the system. • new applications may become available over time. • Therefore, we cannot rely on any “logs" to generate policies for them. Our approach is as follows: • For objects that are created after policy deployment: • their labels will be set to be the same as that of the subject that created them.

26. Limiting Trust • Authors have incorporated features in PPI to reduce the scope and nature of trust placed on different programs. • These Features are : • Invulnerable and Flow-Aware Applications. • Context-aware Trust.

27. Invulnerable and Flow-Aware Applications. • invulnerable applications: • All outputs of themcontinue to have high integrity even after reading low-integrity inputs. • E.g : ssh server • Flow-aware applications • can simultaneously handle inputs with dierent integrity levels. • They keep track of which inputs affect which outputs, and label the outputs appropriately. • web-browsers

28. Context-aware Trust • Their approach, therefore, is to limit trust to the specific input contexts in which an application is believed to be capable of protecting itself.

29. Enforcement Framework: • The design is a hybrid system consisting of two components: • a user-level library. • a kernel-resident checker. • Integrity-critical enforcement action are performed by the kernel component, while “functionality enhancement” features are relegated.

30. Enforcement Framework: • In the implementation : the kernel level component is realized using LSM (Linux Security Modules) • They use the security hooks of LSM to enforce information policies.

31. Performance Overheads • They present both the microbenchmark and macrobenchmarkresults for PPI. • For microbenchmark evaluation, • They used LMbench version 3 to check the performance degradation of popular system calls. • Results :

32. Performance Overheads • For macrobenchmark evaluation, • They measured 3 typical applications running within PPI during runtime. • The runtime overhead for applications in PPI is about 5% or less.

33. Limitations • The approach cannot support arbitrary untrusted software. • Their work does not focus on confidentiality or availability, but it still contributes to them in two ways. • solutions for confidentiality and availability must build on solutions for integrity. • Their techniques halt malware that exploits integrity violations to attack confidentiality

34. Related Work: • Biba Model • It has a strict “no read down and no write up” policy. • Low-water Mark Model • It relaxes this strict policy to permit subjects to be downgraded when they read low-integrity inputs. • LOMAC • a prototype implementation of low-water mark model on Linux, addresses the “self-revocation" problem to a certain extent.

35. Related Work • SLIM (Simple Linux Integrity Model) • is based on the LOMAC model. • IX and etc…

36. Conclusion • By enforcing information flowpolicies, our approach provides positive assurancesagainst malware from damaging system integrity. • Authors have developed several techniques to automate the generation of low level information flow policies from data contained in software package managers, and logs that capture normal usage of these systems.

37. Questions?