Upgradeability of 3rd Party Libraries: A Security Perspective

Presentation at the University of Victoria, BC (Monday, November 24), and the University of British Columbia, Vancouver, BC (Friday, November 28).

The presentation was part of the Software Security course at UVic, and of the Software Engineering course at UBC.

Transcript

1. Upgradeability  of  3rd  Party   Libraries:  A  Security  Perspec9ve   Arie  van  Deursen  /  @avandeursen   Del?  University  of  Technology   Joint  work  with  Steven  Raemaekers  (ING),  Mircea  Cadariu  (SIG),     Eric  Bouwers  (SIG),  and  Joost  Visser  (SIG)   1   flickr.com/yuhmag8cal1  
2. Outline   1.  Introduc9on:  Libraries  and  security   2.  Upgrading  behavior  in  Java  /  maven   3.  Vulnerable  dependencies  in  maven     4.  Summary  and  outlook   2  
3. Top  Maven  Downloads  (12  months)   Source:  “The  unfortunate  reality  of  insecure  libraries”.  Contrast  Security,  2014   3  
4. %  Vulnerable   Downloads?   4   Source:  “The  unfortunate  reality  of  insecure  libraries”.  Contrast  Security,  2014  
5. OWASP  Top  10   1.  Injec9on   2.  Broken  authen9ca9on   3.  Cross-­‐site  scrip9ng   4.  Insecure  direct  object   references   5.  Security   misconfigura9on   6.  Sensi9ve  data   exposure   7.  Missing  func9on  level   access  control   8.  Cross  site  request   forgery   9.  Using  components   with  known   vulnerabili9es   10. Unvalidated  redirects   and  forwards   5   hhps://www.owasp.org/index.php/Top_10_2013-­‐Top_10  
6. Hello  JP  Morgan   6  
8. Disclosure  Triggers  Ahacks   Before  we  knew  it:  An   empirical  study  of  zero-­‐ day  ahacks  in  the  real   world.  Leyla  Bilge  and   Tudor  Dimitras,    CCS  2012   8  
9. Act  Fast  (Or  Else:  Backdoor)   9   Automated  a*acks  began  compromising  Drupal  7   websites  that  were  not  patched  or  updated  to   Drupal  7.32  within  hours  of  the  announcement  of   SA-­‐CORE-­‐2014-­‐005  -­‐  Drupal  core  -­‐  SQL  injecJon.       You  should  proceed  under  the  assumpJon  that   every  Drupal  7  website  was  compromised  unless   updated  or  patched  before  Oct  15th,  11pm  UTC,   that  is  7  hours  aQer  the  announcement.     Simply  updaJng  to  Drupal  7.32     will  not  remove  backdoors.  
10. Digital  ID  for  The  Dutch   •  Ruby  on  Rails  <  3.2.11:   CVE-­‐2013-­‐0155/0156   –  SQL  Injec9on,  code   execu9on,  bypass   authen9ca9on,  denial  of   service   –  Fix  involved  a  regression   •  2.0.x  affected,  not  fixed   –  Must  upgrade  to  2.3   •  9M  Dutch  ci9zens     •  Tax  payments   •  DigiD  immediately   upgraded   –  Site  was  taken  off  line   for  9  hours   –  Mostly  for  regression   tesJng  purposes   10   Arie  van  Deursen,  “Design  for  Upgradability  and  the  Rails  DigiD  Outage”,     hhp://avandeursen.com,  January  2013  
11. 11     “A  vulnerability  that  allows     easy  remote  code  execuJon  /  shell  access     and  a  security  patch  that  breaks  compaJbility.       You  are  doing  great  Rails  team!     This  is  pre*y  much  the  death  of  Rails  reputaJon”     hhp://weblog.rubyonrails.org/2013/1/8/Rails-­‐3-­‐2-­‐11-­‐3-­‐1-­‐10-­‐3-­‐0-­‐19-­‐and-­‐2-­‐3-­‐15-­‐have-­‐ been-­‐released/#comment-­‐762338772  
12. Upgrading  Intricacies   System   •  2004:  First  version.   –  Maven   –  Acegi  Security  v1.0   –  Spring,  Struts,  JSP   •  2004-­‐2011   –  Dependencies  carved  in  stone   •  2011:  Single  sign  on  needed   –  Atlassian  Crowd   Libraries  Issues   •  Crowd  ✖  Acegi   •  Acegi  included  in  Spring  2   •  Crowd  needs  Spring  3   •  Upgrade  to  Spring  3  needed   •  Struts  JSP  2    ✖  Spring  3   •  Upgrade  to  JSP  3  needed   •  JSP3  syntax  ✖  JSP2  syntax   Total  upgrade  effort:  1  week   12   Steven  Raemaekers,  Arie  van  Deursen,  Joost  Visser.  Measuring  so?ware  library   stability  through  historical  version  analysis.  ICSM  2012:  378-­‐387  
13. Upgradeability,     Security,  and  Availability   •  Third  party  libraries  come  with  vulnerabili9es   aQer  system-­‐go-­‐live   •  Upon  disclosure,  fast  upgrading  is  required   •  During  upgrade,  a  system  is   –  Either  exposed  to  security  risk;   –  Or  not  available.   13   We  must   thoroughly   understand   upgradeability  
14. The  Maven  Dataset   •  150,000  released  jar  files;  100,000  with  source   •  As  in  Maven  Central  on  July  30,  2011   •  With  resolved  usage  data   14   Steven  Raemaekers,  Arie  van  Deursen,  Joost  Visser.   The  maven  repository  dataset  of  metrics,  changes,  and  dependencies.  MSR  2013:  221-­‐224   Julius  Davies,  Daniel  M.  German,  Michael  W.  Godfrey,  and  Abram  Hindle.     So?ware  Ber9llonage  -­‐  determining  the  provenance  of  so?ware  development  ar9facts.  EMSE,  2013  
15. Breaking  Changes?   Binary  IncompaJbiliJes   Focus  of  study:   Removals:  Interface,  class,  method,  or  field   Changes:      Nr  of  parameters,  or  change  in                                            field  /  parameter  /  return  type   15   “Pre-­‐exisJng  client  binaries  must  link  and  run  with  new  releases   of  the  component  without  recompiling.”  -­‐-­‐-­‐  the  CLIRR  tool.   flickr.com/photos/dullhunk/  
16. Breaking  Changes  in  Maven   16   Steven  Raemaekers,  Arie  van  Deursen,  Joost  Visser.     Seman9c  Versioning    versus  Breaking  Changes:    A  Study  of  the  Maven  Repository.  SCAM  2014.  
17. Is  Anything  Being  Broken?   •  Maven  libraries  depend  on  ...  each  other   – S  uses  L;     – L  updated  to  L’;   – Will  S  compile  with  L’?   •  Assess  impact  by  step  by  step    injecJon  of   breaking  changes   17   Let’s  do  this  for  48,000  (L,L’)-­‐pairs     where  L  is  used  in  some  S.   Steven  Raemaekers,  Arie  van  Deursen,  Joost  Visser.     Injec9ng  Breaking  API  Changes  to  Assess  the  Impact  of  Library  Updates.  TUD-­‐SERG-­‐2014-­‐020.  
18. Compila9on  Impact   18  
19. Does  Library  Size  Maher?   19   0 2 4 6 8 10 log(#Breaking changes) 2 3 4 5 6 7 8 9 log(Number of methods)
20. Does  Library  Age  Maher?   •  Maturity  =  release  index  =   number  of  versions  of  library  un9l  now   •  Correlate  release  index  with  #  errors   •  Very  weak  correlaJon  (r  =  0.1078)   [  Size  and  age  correla9on?  Only  0.0278  ]   20  
21. When  Is  Impact  Scahered?   21   When  the     library  is   large  
22. Does  Versioning  Help?   22   Steven  Raemaekers,  Arie   van  Deursen,  Joost  Visser.     Seman9c  Versioning    versus   Breaking  Changes:    A  Study   of  the  Maven  Repository.   SCAM  2014.  
23. Seman9c  Versioning   Major  .  Minor  .  Patch:   •  Major:  incremented  when     incompa9ble  API  changes  are  made   •  Minor:  incremented  when  func9onality  is   added  in  backward  compa9ble  manner   •  Patch:  incremented  when     backward-­‐compa9ble  bug  fixes  are  made   23   “Based  on  pre-­‐exisJng  widespread  common  pracJces”   “Seman9c   Versioning”   semver.org  
24. 24   Breaking   Changes  versus   Update  Type?  
25. Breaking  Changes  over  Time   25  
26. Depreca9on  to  the  Rescue?   “DeprecaJng  exisJng  funcJonality  is  a  normal   part  of  soQware  development  and  is  oQen   required”  (semver)     Depreca9on  in  seman9c  versioning:   1.  Update  documenta9on   2.  Introduce  depreca9on  in  minor  release   3.  A?er  that  remove  method  in  major  release   26  
27. Depreca9on  to  the  Rescue?   Depreca?on  pa@ern   Frequency   %  Update  pairs     Delete  public  method   (no  depreca9on)   86449   33.0%   Add  public  depreca9on   (no  dele9on)   793     0.3%   Delete  deprecated  method   0   0.0%   27  
28. Update  Lags   28   L1 uses Jan 1 May 1 Feb 1 Mar 1 Apr 1 S1 L2 S2 S3 next ver. L3 Aug 1 S3-L Update lag patch major minor One minor release lagging
29. Update  Lags  in  Maven   Correla9on  with  number  of  breaking  changes?   Hardly:  0.14  for  minor  releases   0.02  and  0.08  for  patch  and  major  releases     29   Number  of  major  /  minor  /  patch  versions  lagging  behind   Breaking  changes  do  not  explain  update  lags!  
30. Maven  Summary   •  Breaking  changes  are  omni-­‐present   •  Breaking  changes  actually  break  things   •  Large  libraries  cause  more  pain   •  Versioning  does  not  help   •  Depreca9on  does  not  help   30   0 2 4 6 8 10 log(#Breaking changes) 2 3 4 5 6 7 8 9 log(Number of methods)
31. Maven  Library  Security  Monitoring?   31   Cadariu,  Bouwers,  van  Deursen,  Visser.  Tracking  known  security   vulnerabili9es  in  third-­‐party  components.  TUD-­‐SERG-­‐2014-­‐022  
33. 12,100  Systems  in  Maven  Central     20%  Have  Vulnerable  Dependencies   33  
34. 75  Industrial  Systems     using  Maven   34   www.sig.eu   50-­‐1000  KLOC   50-­‐300     Dependencies  
35. 75  Industrial  Systems  using  Maven:     72%  Have  Vulnerable  Dependencies   35  
36. #  Vulnerable  Components:  0-­‐7   36  
37. Most  Popular  Vulnerabili9es   37  
38. Adop9on  of  “Alert  Service”   •  Integrated  in  SIG  monitoring  setup   •  Interviews:     4  selected  alerts  given  to  4  consultants   •  Alert  usefulness  analysis:   Memos  for  449  unfiltered  alerts  of  34   different  systems  given  to  4  consultants     38  
39. Interview  Findings   •  Without  monitoring  service,  consultants   would  not  have  considered  outdated  libraries   •  Alert  processing  takes  lihle  9me   •  Follow  up  ac9on  is  no9fica9on  of  stakeholders   •  Alerts  are  easy  to  communicate   •  Resolu9ons:  Upgrade  or  drop  dependency   •  Long  term  maintenance  has  low  priority   39  
40. Alert  Analysis   •  Mostly  useful   •  Consultants  dis9nguished:   1.  Use  in  code   2.  Use  for  tes9ng  only   3.  Non-­‐use  but  with  declared  dependency   4.  Non-­‐use  /  false  posi9ve.   •  CVE-­‐2010-­‐3700:  Bank’s  security     officer  immediately  took  ac9on.   40  
41. Implica9ons:  Library  Developers   •  Take  breaking  changes  seriously   •  Use  encapsula9on  appropriately   •  Use  depreca9on  before  dele9on   •  Adopt  seman9c  versioning  rigorously   •  The  test  of  version  x.y  should  pass  on  x.(y+1).   •  Know  what  you  break:  Monitor  API  usage   41  
42. Implica9ons:  API  clients   •  Security  demands  upgrading  a?er  go-­‐live   •  Availability  demands  minimizing  upgrade  9me   •  Value  encapsula9on;  localize  dependencies.   •  Test  how  you  interact  with  your  libraries   •  Don’t  trust  semver  promises   42  
43. Implica9ons:  Research   •  Widen  study  of  breaking  changes  to  different   eco-­‐systems.   •  Give  developers  safe  means  to  sa9sfy  their   deep  need  for  introducing  breaking  changes   •  Give  clients  effec9ve  ways  to  assess  and   encapsulate  upgrade  impact   43  
44. Addi9onal  Reading   •  Steven  Raemaekers,  Arie  van  Deursen,  Joost  Visser.  Seman9c   Versioning    versus  Breaking  Changes:    A  Study  of  the  Maven   Repository.  SCAM  2014.   •  Cadariu,  Bouwers,  van  Deursen,  Visser.  Tracking  known  security   vulnerabili9es  in  third-­‐party  components.  TUD-­‐SERG-­‐2014-­‐022   •  Steven  Raemaekers,  Arie  van  Deursen,  Joost  Visser.  Injec9ng   Breaking  API  Changes  to  Assess  the  Impact  of  Library  Updates.  TUD-­‐ SERG-­‐2014-­‐020.   •  Joseph  Hejderup.  Library  security  in  NodeJS.  MSc  Thesis,  Del?   University  of  Technology,  2015.   44