1. M A L W A R E C S 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. S ANDBOXING 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. S ANDBOXING 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. T HE A PPROACH : 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. G OALS OF A PPROACH 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. S ALIENT F EATURES : Flexible decomposition of high-level policies into low-level policies. Automated analysis for generating enforeceable policies. A flexible enforcement framework. Mechanisms for limiting trust.

10. P OLICY F RAMEWORK *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. P OLICY F RAMEWORK When referring to applications : They use the term [ trust level ] instead of [ integrity level ]. Benign applications: 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. P OLICY F RAMEWORK Untrusted applications : 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. P OLICY F RAMEWORK 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. P OLICY F RAMEWORK 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. A UTOMATING POLICY D EVELOPMENT 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. C OMPUTING D EPENDENCIES, C ONTEXTS AND L ABELS Deriving Initial Object Labels. Initial object labels are derived using the following steps: Mark all packages that depend on untrusted packages as untrusted. Label all objects that belong to untrusted packages 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. P OLICY G ENERATION 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. 1 ST P HASE 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. 1 ST P HASE 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. 2 ND P HASE : 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. 2 ND P HASE 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. 2 ND P HASE 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. 3 RD P HASE : A problem in 2 nd 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. 3 RD 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. 4 TH P HASE : 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. L IMITING T RUST 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 them continue 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. C ONTEXT - AWARE T RUST 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. E NFORCEMENT F RAMEWORK : 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. E NFORCEMENT F RAMEWORK : 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. P ERFORMANCE O VERHEADS They present both the microbenchmark and macrobenchmark results for PPI. For microbenchmark evaluation, They used LMbench version 3 to check the performance degradation of popular system calls. Results :

32. P ERFORMANCE O VERHEADS 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. L IMITATIONS 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. R ELATED W ORK : 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. R ELATED W ORK SLIM (Simple Linux Integrity Model) is based on the LOMAC model. IX and etc…

36. C ONCLUSION By enforcing information flow policies, our approach provides positive assurances against 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. Q UESTIONS ?