precisely characterizing security impact in a flood of
play

Precisely Characterizing Security Impact in a Flood of Patches via - PowerPoint PPT Presentation

Precisely Characterizing Security Impact in a Flood of Patches via Symbolic Rule Comparison Qiushi Wu , Yang He, Stephen McCamant, and Kangjie Lu 1 Why do we need to identify security bugs? 2 Motivation The overwhelming number of bugs


  1. Precisely Characterizing Security Impact in a Flood of Patches via Symbolic Rule Comparison Qiushi Wu , Yang He, Stephen McCamant, and Kangjie Lu 1

  2. Why do we need to identify security bugs? 2

  3. Motivation ● The overwhelming number of bugs reports ○ ○ ■ 3

  4. Motivation ● The overwhelming number of bugs reports ● Patch propagation in derivative programs is hard and expensive ○ https://developer.solid-run.com/knowl 4 edge-base/linux-based-os-for-ib8000/

  5. Motivation ● The overwhelming number of bugs reports ○ ● Patch propagation in derivative programs is hard and expensive Maintainers are prioritizing to fix security bugs. Unrecognized security bugs may be left unpatched! 5

  6. Our goal:

  7. How to identify patches for security bugs? 7

  8. Traditional approaches: ● Text-mining ○ ● Statistical analysis ○ Limitations: 8

  9. Limitations of traditional approaches: CVE-2014-8133 Permission bypass commit 41bdc78544b8a93a9c6814b8bbbfef966272abbe Author: Andy Lutomirski <luto@amacapital.net> Date: Thu Dec 4 16:48:16 2014 -0800 x86/tls: Validate TLS entries to protect espfix Installing a 16-bit RW data segment into the GDT defeats espfix. AFAICT this will not affect glibc, Wine, or dosemu at all. Signed-off-by: Andy Lutomirski <luto@amacapital.net> Acked-by: H. Peter Anvin <hpa@zytor.com> Cc: stable@vger.kernel.org Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: security@kernel.org <security@kernel.org> Cc: Willy Tarreau <w@1wt.eu> Signed-off-by: Ingo Molnar <mingo@kernel.org> 9

  10. We prefer a program analysis--based method ● Understand the semantics of patches and bugs precisely ● A bug is a security bug if it causes security impacts when triggered. ● A patch is for a security bug when it blocks the security impacts 10

  11. How to know if a patch blocks security impacts? 11

  12. A security impact = A security-rule violation Security rules are coding guidelines used to prevent security bugs. Security-rule violations cause security impacts. We thus check if a patch blocks security-rule violations 12

  13. Common security rules Rule 1: In-bound access Rule 3: Use after initialization Rule 4: Permission check Rule 2: No use after free before sensitive operations 13

  14. Violations for common security rules Rule 1: In-bound access Rule 3: Use after initialization violation violation Uninitialized use Out-of-bound access Rule 4: Permission check Rule 2: No use after free before sensitive operations violation violation Use-after-free Permission bypass 14

  15. A patch blocks security impacts if: If we can prove the following conditions: Condition 1: The unpatched version of code violates a security rule. Condition 2: The patched version of code does not violate the security rule. 15

  16. Challenge:

  17. Intuition: two unique properties under-constrained symbolic execution

  18. Property 1: Constraints model violations Security-rule violations can be modeled as constraints Example: Buffer access: Constraints for out-of-bound access: Index ⩾ UpBound Index ⩽ LowBound 18

  19. Property 2: Conservativeness Under-constrained symbolic execution is conservative. ● False-positive solutions ○ If the constraints are solvable, this can be a false positive. ● Proved unsolvability ○ If it cannot find a solution against constraints, they are indeed unsolvable. 19

  20. Leverage the properties for determining the security-rule violations ● Patch-related operations can be modeled as symbolic constraints ○ ● To show the patched version won’t violate a security rule ○ violating ● To show the unpatched version will violate the security rule non-violating ○ 20

  21. Our approach: Symbolic rule comparison 1. Construct opposite constraint sets for the patched and unpatched version 2. Check the unsolvability of these constraint sets 3. Confirm the patches for security bugs if both constraint sets are unsolvable 21

  22. Rationale behind our approach ● For a security rule, the patched version NEVER violate it ○ 22

  23. Rationale behind our approach ● For a security rule, the patched version NEVER violate it ○ ● In the situations that opposite to conditions of the patch, the unpatched version MUST violate this security rule ○ 23

  24. Rationale behind our approach ● For a security rule, the patched version NEVER violate it ○ ● In the situations that opposite to conditions of the patch, the unpatched version MUST violate this security rule ○ ● The patch changes the code from an unsafe state to a safe state ○ Precisely confirmed with property 2 24

  25. Rationale behind our approach ● For a security rule, the patched version NEVER violate it ○ ● In the situations that opposite to conditions of the patch, the unpatched version MUST violate this security rule ○ ● The patch changes the code from an unsafe state to a safe state The patch fixed a security bug with the security impact that corresponding to the security rule violation. 25

  26. A concrete example 26

  27. STEP 1: Symbolically analyzing patched code // CVE-2012-6712 1 int iwl_sta_ucode_activate(... , u8 sta_id) { 2 + if (sta_id >= IWLAGN_STATION_COUNT) { 3 + IWL_ERR(priv, "invalid sta_id %u", sta_id); 4 + return -EINVAL; 5 + } 6 7 if (!(priv->stations[sta_id].used )) 8 IWL_ERR(priv,"Error active station id %u " 9 "addr %pM\n", 10 sta_id, priv->stations[sta_id].sta.sta.addr); 11 12 ... 13 return 0; 14 } 15 27

  28. STEP 1: Symbolically analyzing patched code Identify security operations. // CVE-2012-6712 1 int iwl_sta_ucode_activate(... , u8 sta_id) { 2 + if (sta_id >= IWLAGN_STATION_COUNT) { 3 + IWL_ERR(priv, "invalid sta_id %u", sta_id); 4 + return -EINVAL; 5 + } 6 7 if (!(priv->stations[sta_id].used )) 8 IWL_ERR(priv,"Error active station id %u " 9 "addr %pM\n", 10 sta_id, priv->stations[sta_id].sta.sta.addr); 11 12 ... 13 return 0; 14 } 15 28

  29. STEP 1: Symbolically analyzing patched code Identify security operations. // CVE-2012-6712 1 int iwl_sta_ucode_activate(... , u8 sta_id) { 2 + if (sta_id >= IWLAGN_STATION_COUNT) { 3 + IWL_ERR(priv, "invalid sta_id %u", sta_id); 4 Extract critical variable. + return -EINVAL; 5 + } 6 7 if (!(priv->stations[sta_id].used )) 8 IWL_ERR(priv,"Error active station id %u " 9 "addr %pM\n", 10 sta_id, priv->stations[sta_id].sta.sta.addr); 11 12 ... 13 return 0; 14 } 15 29

  30. STEP 1: Symbolically analyzing patched code Identify security operations. // CVE-2012-6712 1 int iwl_sta_ucode_activate(... , u8 sta_id) { 2 + if (sta_id >= IWLAGN_STATION_COUNT) { 3 + IWL_ERR(priv, "invalid sta_id %u", sta_id); 4 Extract critical variable. + return -EINVAL; 5 Slicing + } 6 7 if (!(priv->stations[sta_id].used )) Identify vulnerable operations. 8 IWL_ERR(priv,"Error active station id %u " 9 "addr %pM\n", 10 sta_id, priv->stations[sta_id].sta.sta.addr); 11 12 ... 13 return 0; 14 } 15 30

  31. STEP 2: Collecting and construct constraints for patched code Collecting constraints // CVE-2012-6712 1 int iwl_sta_ucode_activate(... , u8 sta_id) { 2 Constraints source Constraints + if (sta_id >= IWLAGN_STATION_COUNT) { 3 + IWL_ERR(priv, "invalid sta_id %u", sta_id); 4 Security operations + return -EINVAL; 5 + } 6 7 if (!(priv->stations[sta_id].used )) 8 Slice IWL_ERR(priv,"Error active station id %u " 9 "addr %pM\n", 10 Artificial constraints sta_id, priv->stations[sta_id].sta.sta.addr); 11 (Security rules) 12 ... 13 Violating security rules return 0; 14 } 15 31

  32. STEP 3: Solving constraints for patched code Collecting constraints // CVE-2012-6712 1 int iwl_sta_ucode_activate(... , u8 sta_id) { 2 Constraints source Constraints + if (sta_id >= IWLAGN_STATION_COUNT) { 3 + IWL_ERR(priv, "invalid sta_id %u", sta_id); 4 Security operations + return -EINVAL; 5 + } 6 7 if (!(priv->stations[sta_id].used )) 8 Slice IWL_ERR(priv,"Error active station id %u " 9 "addr %pM\n", 10 Artificial constraints sta_id, priv->stations[sta_id].sta.sta.addr); 11 (Security rules) 12 ... 13 These constraints are unsolvable! return 0; 14 } 15 32

  33. STEP 3: Solving constraints for patched code // CVE-2012-6712 1 int iwl_sta_ucode_activate(... , u8 sta_id) { 2 + if (sta_id >= IWLAGN_STATION_COUNT) { 3 + IWL_ERR(priv, "invalid sta_id %u", sta_id); 4 The patched version won’t + return -EINVAL; 5 violate the security rule. + } 6 7 if (!(priv->stations[sta_id].used )) 8 IWL_ERR(priv,"Error active station id %u " 9 "addr %pM\n", 10 sta_id, priv->stations[sta_id].sta.sta.addr); 11 12 ... 13 These constraints are unsolvable! return 0; 14 } 15 33

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend