Differences

This shows you the differences between two versions of the page.

Link to this comparison view

p_lkrg:Threat_model [2017/07/12 16:36]
pi3
p_lkrg:Threat_model [2017/10/28 14:44] (current)
pi3
Line 18: Line 18:
  
 \\ \\
-**Scenario 2.** describes initial attacks on the kernel via any kernel vulnerability and it involves a kernel memory write. Current version of the project might partially protect against a subset of such writes - namely, those involving machine code changes (or effectively equivalent changes), ​but not data changes. +**Scenario 2.** describes initial attacks on the kernel via any kernel vulnerability and it involves a kernel memory write. Current version of the project might partially protect against a subset of such writes - namely, those involving machine code changes (or effectively equivalent changes), ​as well as any attack which involves overwriting any process;credentialsFor more information please read [[p_lkrg:​Main#​Exploit-Detection|this]] chapter.
-Current version of LKRG doesn'​t comprehensively address this subset of attacks but it'in the priority list for the future work"Exploit Detection" feature will be developed (using "​Protected Features"​ architecture) which should cover that problem. From the beginning the project was designed to "​evolve"​ in the direction to detect (might also partially protect) kernel exploit scenarios via kernel vulnerabilities.+
  
 \\ \\
Line 38: Line 37:
  
 \\ \\
-====== Attacking user-mode client ​======+====== LKRG experimental branch ====== 
 +===== Attacking user-mode client =====
 By creating communication channel and user-mode client of the project, LKRG created new potential vectors of attack. These attacks can be summarized as follows: By creating communication channel and user-mode client of the project, LKRG created new potential vectors of attack. These attacks can be summarized as follows:
  
Line 50: Line 50:
  
 **Scenario 1.** is addressed by creating a new subset of processes in the system - "​protected process"​. It guarantees that no one in user-mode (including root) won't be able to change the state of running process at any time. Also it guarantees that none of the secrets can be ever discovered by anyone in user-mode (including root). **Scenario 1.** is addressed by creating a new subset of processes in the system - "​protected process"​. It guarantees that no one in user-mode (including root) won't be able to change the state of running process at any time. Also it guarantees that none of the secrets can be ever discovered by anyone in user-mode (including root).
-Only another "​protected process"​ has rights to establish 3rd party communication (e.g. sending signals). For more details please take a look at the section [[p_lkrg:Main#​Protected-process|Protected Process.]]+Only another "​protected process"​ has rights to establish 3rd party communication (e.g. sending signals). For more details please take a look at the section [[p_lkrg:Protected_Features#​Protected-process|Protected Process.]]
  
-**Scenario 2.** is addressed by creating a new subset of files in the filesystem - "​protected file". It guarantees that no one in user-mode (including root) won't be able to change the content of the file at any time. File can still be normally executed and read if the owner of the file decides to give that rights to "​other"​ users. For more details please take a look at the section [[p_lkrg:Main#​Protected-file|Protected File.]]+**Scenario 2.** is addressed by creating a new subset of files in the filesystem - "​protected file". It guarantees that no one in user-mode (including root) won't be able to change the content of the file at any time. File can still be normally executed and read if the owner of the file decides to give that rights to "​other"​ users. For more details please take a look at the section [[p_lkrg:Protected_Features#​Protected-file|Protected File.]]
  
 **Scenario 3.** and **4.** are a bit tricky. Many users believe that CAP_SYS_RAWIO capability controls raw memory and disk access - but that's incorrect. There is no way to block raw disk access through any capabilities. CAP_SYS_RAWIO limits mostly raw memory access (it has some other restriction not related to the discussion like ioports). Even without CAP_SYS_RAWIO an attacker with appropriate rights (any root process or any process with appropriate DAC rights) might open e.g. /​dev/​sda[0-x] device and overwrite this "​slot"​ where victim'​s file is. **Scenario 3.** and **4.** are a bit tricky. Many users believe that CAP_SYS_RAWIO capability controls raw memory and disk access - but that's incorrect. There is no way to block raw disk access through any capabilities. CAP_SYS_RAWIO limits mostly raw memory access (it has some other restriction not related to the discussion like ioports). Even without CAP_SYS_RAWIO an attacker with appropriate rights (any root process or any process with appropriate DAC rights) might open e.g. /​dev/​sda[0-x] device and overwrite this "​slot"​ where victim'​s file is.
Line 62: Line 62:
  
 \\ \\
-====== Protected Logs ======+===== Protected Logs =====
 If LKRG detects any inconsistency in the kernel, it generates appropriate log message from the kernel (in the future LKRG might be configurable to crash the kernel). These logs might be forwarded to the remote server or locally consumed in user-mode and written to the appropriate file. An attacker might be changing the kernel state and clean the logs to be able to hide his own activity. To be able to avoid that situation, LKRG created another subset of files in the filesystem which essentially works like "​append"​ files. LKRG enforces that no one in file system (including root) can ever change the content of the file which was already written. The new data can still be written to the same file, but old data can't be modified. If LKRG detects any inconsistency in the kernel, it generates appropriate log message from the kernel (in the future LKRG might be configurable to crash the kernel). These logs might be forwarded to the remote server or locally consumed in user-mode and written to the appropriate file. An attacker might be changing the kernel state and clean the logs to be able to hide his own activity. To be able to avoid that situation, LKRG created another subset of files in the filesystem which essentially works like "​append"​ files. LKRG enforces that no one in file system (including root) can ever change the content of the file which was already written. The new data can still be written to the same file, but old data can't be modified.
-For more details please take a look at the section [[p_lkrg:Main#​Protected-logs|Protected Logs.]]+For more details please take a look at the section [[p_lkrg:Protected_Features#​Protected-logs|Protected Logs.]]
  
  
 \\ \\
-====== Security implications ​====== +===== Security implications ===== 
-To be able to interact with LKRG user must be an administrator of the machine (typically '​root'​ account). This implies thatany new attack surface introduced by the '​core'​ of LKRG will be limited to the scenario of leveraging existing administrator privileges (e.g. '​root'​) to the kernel level access.+To be able to interact with LKRG, a user must be an administrator of the machine (typically '​root'​ account). This implies that any new attack surface introduced by the '​core'​ of LKRG will be limited to the scenario of leveraging existing administrator privileges (e.g. '​root'​) to the kernel level access.
  
-"​Protected Features"​ and future "​Exploit Detection"​ are different, because they intercept some of the functionality directly exposed to the user (e.g. syscalls). If these feature ​are used (PF and/or ED), there is a potential problem ​if any hooking routine is badly written ​- in that case user can have an extra kernel surface to attack. +"​Protected Features"​ and future "​Exploit Detection"​ are different, because they intercept some of the functionality directly exposed to the user (e.g. syscalls). If these features ​are used (PF and/or ED), there is a potential problem ​in case of any hooking routine is incorrectly ​written. In that scenario ​user can have an extra kernel surface to attack. 
-In reality LKRG interceptions are pretty simple (most of the time just checking registers value during the entrance to function/​syscall) and shouldn'​t be problematic.+In realityLKRG interceptions are pretty simple (most of the time just checking registers value during the entrance to function/​syscall) and shouldn'​t be problematic.
p_lkrg/Threat_model.1499902583.txt · Last modified: 2017/07/12 16:36 by pi3
 
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 3.0 Unported
Recent changes RSS feed Donate to DokuWiki Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki Powered by OpenVZ Powered by Openwall GNU/*/Linux Bookmark and Share