Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Security is hard, but we can't go shopping (RailsConf 2013)

Security is hard, but we can't go shopping (RailsConf 2013)

The last few months have been pretty brutal for anyone who depends on Ruby libraries in production. Ruby is really popular now, and that’s exciting! But it also means that we are now square in the crosshairs of security researchers, whether whitehat, blackhat, or some other hat. Only the Ruby and Rails core teams have meaningful experience with vulnerabilites so far. It won’t last. Vulnerabilities are everywhere, and handling security issues responsibly is critical if we want Ruby (and Rubyists) to stay in high demand.

I’ll discuss responsible disclosure, as well as repsonsible ownership of your own code. How do you know if a bug is a security issue, and how do you report it without tipping off someone malicious? As a Rubyist, you probably have at least one library of your own. How do you handle security issues, and fix them without compromising apps running on the old code? Don’t let your site get hacked, or worse yet, let your project allow someone else’s site to get hacked! Learn from the hard-won wisdom of the security community so that we won’t repeat the mistakes of others.

André Arko

April 29, 2013

More Decks by André Arko

Other Decks in Technology


  1. Security is hard

  2. André Arko @indirect   

  3. None
  4. Security is hard

  5. but we can’t go shopping

  6. !

  7. Ruby security releases

  8. None
  9. None
  10. None
  11. this is not normal

  12. None
  13. Rails security releases

  14. None
  15. None
  16. this isn’t normal either

  17. None
  18. None
  19. wait what’s a CVE?

  20. common vulnerabilities and exposures

  21. numbering authorities

  22. apple adobe cisco redhat etc.

  23. cve.mitre.org nvd.nist.gov

  24. minaswan security? vulnerabilities?

  25. dhh + rails not as nice

  26. dhh + rails but we can learn from them

  27. so many gems for everything

  28. so many chances for security issues

  29. rubygems bundler json rexml rack

  30. arel activerecord actionpack activesupport rdoc (rdoc?! yup.)

  31. what should we do?

  32. updating is a pain

  33. updating blocks feature development

  34. updating is insurance

  35. a small cost to mitigate risk

  36. without it failures are catastrophic

  37. !

  38. disclosure liability lawyers

  39. updating is hard work !

  40. but updating is worth it

  41. update sleep well at night !

  42. reporting security issues

  43. responsible disclosure

  44. the worst except for all the other options

  45. the best yet because everyone ends up unhappy

  46. !

  47. but no one ends up screwed

  48. disclosure companies hate it

  49. responsible clever, triumphant hackers hate it

  50. rewards!!

  51. rewards!! maybe everyone ends up happy?

  52. facebook

  53. None
  54. facebook $500 minimum no maximum

  55. github

  56. None
  57. github no stated policy $? maximum

  58. engine yard

  59. None
  60. engine yard no compensation $0 maximum

  61. you anyway, back to

  62. find a bug? what if you

  63. questions ask yourself two

  64. I shouldn’t? can I access something

  65. other people? can I disable something for

  66. disclose responsibly if the answer was yes

  67. publicly contact an author before reporting

  68. look for a security policy email in gemspec email on

  69. have empathy work together

  70. if all else fails

  71. fix it! if all else fails

  72. finally, what about your gems?

  73. your gems are security vulnerabilities waiting to happen

  74. unless your code is perfect (and you want to buy

    this real estate in Florida)
  75. easy sympathetic discoverer

  76. easy write fix, review fix release + announce

  77. medium problem in the wild

  78. medium announce if safe fix ASAP, test fix release +

  79. hard researcher out for glory

  80. hard respond ASAP set expectations update every 24-48h fix +

    release + thanks
  81. make it as easy as possible

  82. personally gemspec email github email

  83. on a team security address PGP key disclosure policy

  84. ecosystem mailing list for announcing security issues and releases

  85. bit.ly/ruby-sec-ann

  86. go shopping we can !"#$ %&'(

  87. questions?