2012 S&P Paper Reading Session1

420 views

Published on

Published in: Engineering, Education, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
420
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

2012 S&P Paper Reading Session1

  1. 1. S&P  2012  Paper  Reading    Session  1:  System  Security Chong-­‐Kuan  Chen  
  2. 2. Outline 1.  A  Framework  to  Eliminate  Backdoors  from   Response-­‐Computable  AuthenHcaHon   2.  Safe  Loading-­‐A  FoundaHon  for  Secure   ExecuHon  of  Untrusted  Programs   3.  ReDeBug:  Finding  Unpatched  Code  Clones  in   EnHre  OS  DistribuHons  
  3. 3. A  Framework  to  Eliminate  Backdoors  from   Response-­‐Computable  Authen<ca<on Shuaifu  Dai,  Tao  Wei,  Chao  Zhang,  Tielei  Wang,  Yu   Ding,  Zhenkai  Liang,  Wei  Zou    Beijing  Key  Lab  of  Internet  Security  Technology      University  of  California,  Berkeley
  4. 4. Outline •  IntroducHon   •  Background   – AuthenHcaHon  Model   – Backdoor   •  Proposed  Scheme   – Explicit  response  comparison   – FuncHon  purificaHon   – Backdoor  usability  tesHng   •  EvaluaHon
  5. 5. IntroducHon •  Formalize  authenHcaHon  model   •  Classify  backdoor  to  response-­‐computable   authenHcaHon  (RCA)   •  Propose  new  RCA  framework  to  eliminate   backdoors  
  6. 6. AuthenHcaHon  Model •  The  basic  authenHcaHon   model     •  Two  class  of  authenHcaHon   model   –  Direct  compare  user  response   and  respected  response,   response-­‐computable   authenHcaHon  (RCA)   –  User  response  involves  in   authenHcaHon  progress  
  7. 7. Response-­‐computable  AuthenHcaHon
  8. 8. Backdoor  A[ack  Model •  The  a[acker  has  chance  to  modify  develop   progress  but  cannot  interfere  deployment   environment   •  A[acker  cannot  intercept  code  review  and  tesHng   process.   •  OperaHng  system  is  trusted.     •  Password  database  is    trusted   •  Examples  of  backdoor   – VSFTPD  2.3.4  Backdoor   – Thompson’s  compiler  backdoor  
  9. 9. Type  of  Backdoor •  type  T1  :  bypass  response  comparison     –  Depends  on  user  input(U-­‐trigger  backdoor)   –  Depends  on  global  states(G-­‐trigger  backdoor)     –  Depends  on  internal  states(I-­‐trigger  backdoor)   •  Type  T2  :  controlling  computaHon  of  expected   response   –  Type  T2a  backdoor's  response  computaHon  depends   on  informaHon  other  than  challenge  and  password   –  Type  T2b  is  response  computaHon  collision-­‐based   backdoor
  10. 10. Proposed  Scheme •  This  RCA  framework  include   –  Explicit  response  comparison   –  FuncHon  purificaHon   –  Backdoor  usability  tesHng
  11. 11. Explicit  Response  Comparison •  Decouple  verificaHon  process     – Response  computaHon     – Response  comparison   •  Explicit  Response  Comparison   – Response  comparison  compare  user  response  and   respect  response  only   •  This  step  can  eliminate  T1  backdoor  
  12. 12. FuncHon  purificaHon •  Pure    funcHon’s  characters   –  Without  side  effects   –  DeterminisHc     •  This  step  ensure    response  computaHon  is  a  pure  funcHon   –  Only  challenge  and  password  involve  in  response   computaHon     •  NaPu  components  employ  a  funcHon  level  sandbox     –  Global    state  isolaHon     –  Internal    state  reset.     •  Acer  this  step  T2a  backdoors  are  eliminated.  
  13. 13. Backdoor  usability  tesHng •  This  step  use  collision  tesHng     – Use  sampling  to  check  collision  probability   – find  out  high  collision  algorithms     •  Eliminated    T2b  backdoors.  
  14. 14. Overview  of  Scheme
  15. 15. EvaluaHon •  Performance  overhead   •  Backdoor  usability  tesHng   •  Volunteer-­‐created  backdoor
  16. 16. Safe  Loading-­‐AFounda<on  for  Secure  Execu<on  of   Untrusted  Programs Mathias  Payer,  Tobias  Hartmann  and  Thomas  R.  Gross   ETH  Zurich,  Switzerland
  17. 17. Outline •  IntroducHon   •  Background   –  Socware-­‐based  fault  isolaHon   –  Binary  TranslaHon   –  Policy-­‐based  system  call  authorizaHon   •  A[ack  Vector  To  Loader   –  ExploiHng  the  standard  loader   –  The  late  intercepHon  problem   –  The  loader  black  box   •  Proposed  Scheme   •  EvaluaHon
  18. 18. IntroducHon •  SFI  was  deployed  widely  to  secure  program   execuHon   •  Standard  loader  exposes  secure  risk  to  escape   SFI   •  This  paper  replaces  standard  loader  by  secure   loader  out  of  sandbox  to  eliminate  a[ack  to   loader    
  19. 19. Socware-­‐based  Fault  IsolaHon •  Socware-­‐based  fault  isolaHon(SFI)  has  been   proposed  to  secure  program  execuHon   •  With  FFI  framework,  many  security  features  can  be   implement   –  ASLR,  DEP,  stack  canaries   •  Most  of  SFI  frameworks  employ  following  technique   –  Binary  TranslaHon   –  Policy-­‐based  system  call  authorizaHon  
  20. 20. Binary  TranslaHon •  Binary  TranslaHon  (BT)   – Libdetox,  Vx32,  Strata  sanbox  system   – Instrument  applicaHon  behavior
  21. 21. Policy-­‐based  System  Call  AuthorizaHon •  Policy-­‐based  system  call  authorizaHon   – System  call  trace  from  sandbox   – Pre-­‐defined  policy   – To  make  decision  if  the  system  call  can  be   executed
  22. 22. A[ack  Vector  to  Loader •  ExploiHng  the  standard  loader   •  The  late  intercepHon  problem   •  The  loader  black  box  
  23. 23. ExploiHng  the  standard  loader •  Increasing  complexity  of  standard  loader  bring   in  security  risk   – Preload  alternate  libraries   – Replace  the  standard  search  path   – Escalate  privileges
  24. 24. The  Late  IntercepHon  Problem •  ApplicaHon,  BT  and  loader  share  the  same   memory  space   – Loader  may  leak  memory  layout  informaHon   – Break  integrity  of  the  BT
  25. 25. The  Loader  Black  Box •  In  previous  work,  loader  is  the  black  box  and   translated  as  applicaHon   – ApplicaHon  must  has  privileges  to  load  code   – Sandbox  has  no  informaHon  about  memory  layout
  26. 26. Safe  Loading   •  A  lightweight  secure  loader   and  move  secure  loader  into   sandbox  
  27. 27. Privilege  Separate   •  Divide  applicaHon  into  two  domain   – Sandbox  domain  and  applicaHon  domain   •  Sandbox  domain  (secure  loader  and  sandbox)   – Ensure  only  checked  code  loaded     •  ApplicaHon  domain   – Indirect  control  flow  transfer  will  be  checked  by   sandbox  domain
  28. 28. SoluHon  to  Standard  Sandbox •  RestricHng  Privilege  EscalaHon  A[ack   – Secure  loader  only  need  to  relocate  code  and  thus   reduce  a[ack  vector   •  ProtecHng  All  Executed  ApplicaHon  Code   •  Opening  the  Loader  Black  Box
  29. 29. Performance  EvaluaHon
  30. 30. Security  Feature
  31. 31. ReDeBug:  Finding  Unpatched  Code  Clones  in  EnHre   OS  DistribuHons Jiyong  Jang,  Abeer  Agrawal,  and  David  Brumley   Carnegie  Mellon  University
  32. 32. IntroducHon •  Patch  is  the  standard  process  to  fix  and   update  buggy  code   •  Code  clone  is  ocen  appear  in  OS  distribuHon   – Bad  programming  style   – Independent  of  sub-­‐component   – It  is  hard  to  discover  code  clones  in  OS     •  This  paper  propose  system  finding  unpatched   code  clones  in  OS-­‐distribuHon  
  33. 33. Example  of  Code  Clone •  CVE-­‐2009-­‐3720  is  exploit  discovered  and  fixed   in  2009   •  But  the  same  code  clone  appear  386  Hmes   across  Debian,  Ubuntu  package  
  34. 34. Related  Work •  Most  previous  work  like  MOSS,  CCFinde   – DetecHon  all  code  clone  in  system   – Not  scale  enough  to  OS  level   – Language-­‐dependent  
  35. 35. ReDeBug •  This  paper  propose  ReDeBug  system  to  find  code   clone     –  Flexible  scalability   –  Language  agnosHc   –  Lower  false  detecHon  rate   •  ReDeBug  find  code  clone  by  folowing  steps   –  Pre-­‐process  the  source  to  construct  source  database   –  Check  for  unpatched  code  copies   –  Post-­‐process  to  find  exactly  matching  code  
  36. 36. ReDeBug  Workflow
  37. 37. Pre-­‐process 1.  Performs  normalizaHon  and  tokenizaHon     2.  Moves  an  n-­‐length  window  over  the  token   stream.  For  each  window,  the  resulHng  n-­‐ tokens  are  hashed  into  a  Bloom  filter   3.  Stores  the  Bloom  filter  for  each  source  file  in   a  raw  data  format
  38. 38. NormalizaHon   •  Each  line  as  a  basic  unit   – Remove  comments   – Non-­‐ASCII  characters   – Redundant  whitespace  and  newline   – Convert  to  lower  case
  39. 39. TokenizaHon •  Slides  a  window  of  length  n   – Every  n  consecuHve  unit  will  use  to  compare   – Following  are  sample  where  n=2 1 2 3 4 5 1 2 2 3 3 4 4 5
  40. 40. Bloom  Filter Add  element Check  element
  41. 41. Check for Unpatched Code Copies 1.  Extracts  the  original  code  snippet  and  the  c   tokens  of  context  informaHon  from  the  pre-­‐ patch  source   2.  Normalizes  and  tokenizes  the  extracted   original  buggy  code  snippets   3.  Hashes  the  n-­‐token  window  into  a  set  of   hashes   4.  Bloom  filter  set  membership  test
  42. 42. Post-­‐process 1.  Performs  an  exact-­‐matching  test   2.  Excludes  dead  code   3.  reports  only  non-­‐dead  code  to  the  user
  43. 43. Database  Build  Time
  44. 44. Query  Time  
  45. 45. Q&A
  46. 46. Login  Request Challenge Response server client Compute   response Compute   response ’ AuthenHcaHon   Check

×