Security is hard, but we can't go shopping (Ruby on Ales 2013)

Security is hard, but we can't go shopping (Ruby on Ales 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.

4c3ed917e59156a36212d48155831482?s=128

André Arko

March 08, 2013
Tweet

Transcript

  1. Security is hard

  2. André Arko @indirect   

  3. Security is hard

  4. but

  5. we can’t go shopping !

  6. Ruby security releases

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

  11. None
  12. Rails security releases

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

  16. None
  17. wait what’s a CVE?

  18. common vulnerabilities and exposures

  19. numbering authorities

  20. apple adobe cisco redhat etc.

  21. cve.mitre.org nvd.nist.gov

  22. minaswan security? vulnerabilities?

  23. dhh + rails not as nice

  24. dhh + rails but we can learn from them

  25. so many gems for everything

  26. so many chances for security issues

  27. rubygems bundler json rexml rack

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

  29. what should we do?

  30. updating is a pain

  31. updating blocks feature development

  32. updating is insurance

  33. a small cost to mitigate risk

  34. without it failures are catastrophic

  35. !

  36. disclosure liability lawyers

  37. updating is hard work !

  38. but updating is worth it

  39. update sleep well at night !

  40. reporting security issues

  41. responsible disclosure

  42. the worst except for all the other options

  43. the best yet because everyone ends up unhappy

  44. !

  45. but no one ends up screwed

  46. disclosure companies hate it

  47. responsible clever, triumphant hackers hate it

  48. rewards!!

  49. rewards!! maybe everyone ends up happy?

  50. facebook

  51. None
  52. facebook $500 minimum no maximum

  53. engine yard

  54. None
  55. engine yard no compensation $0 maximum

  56. github

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

  59. you anyway, back to

  60. find a bug? what if you

  61. questions ask yourself two

  62. I shouldn’t? can I access something

  63. other people? can I disable something for

  64. disclose responsibly if the answer was yes

  65. publicly contact an author before reporting

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

    github
  67. have empathy work together

  68. if all else fails

  69. fix it! if all else fails

  70. finally, what about your gems?

  71. your gems are security vulnerabilities waiting to happen

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

    this real estate in Florida)
  73. easy sympathetic discoverer

  74. easy write fix, review fix release + announce

  75. medium problem in the wild

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

    announce
  77. hard researcher out for glory

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

    release + thanks
  79. make it as easy as possible

  80. personally gemspec email github email

  81. on a team security address PGP key disclosure policy

  82. ecosystem mailing list for announcing security issues and releases

  83. bit.ly/ruby-sec-ann

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

  85. questions?