2012 S&P Paper Reading Session1

  • 104 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
104
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
1
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. S&P  2012  Paper  Reading    Session  1:  System  Security Chong-­‐Kuan  Chen  
  • 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. 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. Outline •  IntroducHon   •  Background   – AuthenHcaHon  Model   – Backdoor   •  Proposed  Scheme   – Explicit  response  comparison   – FuncHon  purificaHon   – Backdoor  usability  tesHng   •  EvaluaHon
  • 5. IntroducHon •  Formalize  authenHcaHon  model   •  Classify  backdoor  to  response-­‐computable   authenHcaHon  (RCA)   •  Propose  new  RCA  framework  to  eliminate   backdoors  
  • 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. Response-­‐computable  AuthenHcaHon
  • 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. 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. Proposed  Scheme •  This  RCA  framework  include   –  Explicit  response  comparison   –  FuncHon  purificaHon   –  Backdoor  usability  tesHng
  • 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. 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. Backdoor  usability  tesHng •  This  step  use  collision  tesHng     – Use  sampling  to  check  collision  probability   – find  out  high  collision  algorithms     •  Eliminated    T2b  backdoors.  
  • 14. Overview  of  Scheme
  • 15. EvaluaHon •  Performance  overhead   •  Backdoor  usability  tesHng   •  Volunteer-­‐created  backdoor
  • 16. Safe  Loading-­‐AFounda<on  for  Secure  Execu<on  of   Untrusted  Programs Mathias  Payer,  Tobias  Hartmann  and  Thomas  R.  Gross   ETH  Zurich,  Switzerland
  • 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. 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. 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. Binary  TranslaHon •  Binary  TranslaHon  (BT)   – Libdetox,  Vx32,  Strata  sanbox  system   – Instrument  applicaHon  behavior
  • 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. A[ack  Vector  to  Loader •  ExploiHng  the  standard  loader   •  The  late  intercepHon  problem   •  The  loader  black  box  
  • 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. 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. 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. Safe  Loading   •  A  lightweight  secure  loader   and  move  secure  loader  into   sandbox  
  • 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. 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. Performance  EvaluaHon
  • 30. Security  Feature
  • 31. ReDeBug:  Finding  Unpatched  Code  Clones  in  EnHre   OS  DistribuHons Jiyong  Jang,  Abeer  Agrawal,  and  David  Brumley   Carnegie  Mellon  University
  • 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. 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. Related  Work •  Most  previous  work  like  MOSS,  CCFinde   – DetecHon  all  code  clone  in  system   – Not  scale  enough  to  OS  level   – Language-­‐dependent  
  • 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. ReDeBug  Workflow
  • 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. NormalizaHon   •  Each  line  as  a  basic  unit   – Remove  comments   – Non-­‐ASCII  characters   – Redundant  whitespace  and  newline   – Convert  to  lower  case
  • 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. Bloom  Filter Add  element Check  element
  • 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. Post-­‐process 1.  Performs  an  exact-­‐matching  test   2.  Excludes  dead  code   3.  reports  only  non-­‐dead  code  to  the  user
  • 43. Database  Build  Time
  • 44. Query  Time  
  • 45. Q&A
  • 46. Login  Request Challenge Response server client Compute   response Compute   response ’ AuthenHcaHon   Check