5 ms·

There's no "just use X" type of answer in security. Sep 2013 "All versions of the open source Ruby on Rails Web application framework released in the past six

by CCs 13y ago

There's no "just use X" type of answer in security. Sep 2013 "All versions of the open source Ruby on Rails Web application framework released in the past six years have a critical vulnerability that an attacker could exploit to execute arbitrary code, steal information from databases and crash servers." https://groups.google.com/forum/#!topic/rubyonrails-security/61bkgvnSGTQ/discussion https://groups.google.com/forum/#!topic/rubyonrails-security... Nov 2013 "A lingering security issue in Ruby on Rails..." http://threatpost.com/ruby-on-rails-cookiestore-vulnerability-plagues-prominent-websites/103038 http://threatpost.com/ruby-on-rails-cookiestore-vulnerabilit... Dec 2013 "Ruby on Rails security updates patch XSS, DoS vulnerabilities" http://www.infoworld.com/d/security/ruby-rails-security-updates-patch-xss-dos-vulnerabilities-232092 http://www.infoworld.com/d/security/ruby-rails-security-upda...

lmm 13y ago
Rails does plenty of "make life easier for the programmer" things that I would expect to increase the risk of security issues. Do you have those kind of problems for e.g. Haskell?
- deleted 13y ago
  [deleted]
- dtech 13y ago
  Haskell problably has/would have the same kind of problems, but finding examples will be a lot harder in the absence of large well-used web platform à la RoR
  - jerf 13y ago
    If you worked at it, you could create this problem in Haskell. However, it is in fact the case that Haskell would be, in its own way, screaming at you; your configuration (or whatever) parser takes in some text and then returns something of type "IO Configuration"... what is that IO doing there? You don't have to be very skilled in Haskell to stop right there and have a serious think about what's going on. And in the absence of IO, or some other really obviously wrong type signature, there isn't much malicious stuff you can do in the parser layer. You could still have a vulnerability by doing something wrong when given certain configurations, but there's not much we can do about straight-up bugs. Even a proof language will let you make straight-up errors, they'll just force you to deeply, profoundly make the error instead of superficially make it... but we humans are up to the task!
  - einhverfr 12y ago
    Once you are doing functional programming a bunch of classes of problems including a bunch of classes of security problems go away. For example, here, if the guarantee of functional programming is that a given input leads to a given output and has no memory side effects, then your attack surface area is a lot, lot smaller.
  - SparklingCotton 12y ago
    No it simply does not, because the language forces you to write pure functions. The type system invites you to express invariants. There are very fundamental connections between strong typing, program verification, and proofs. http://en.wikipedia.org/wiki/Curry-Howard_correspondence http://en.wikipedia.org/wiki/Curry-Howard_correspondence Thus, the argument that Haskell probably has the same, is simply false. There are large web platforms in Haskell. Yesod is probably the largest eco-system. It is clearly not as well used as RoR, but anyone can dig through large amounts of code to try to find these bugs. What Haskell has that everyone else has are bugs/misunderstandings in how protocols are implemented. Sometimes there can be fundamental bugs in the run-time-system. However, large classes of bugs are fundamentally less likely to appear than in less safe languages.
- rickr 13y ago
  Remember - Rails is a framework for webapps. Haskell is a language. You should be comparing ruby to haskell.
khafra 13y ago
Write everything in Coq.
- tel 13y ago
  Perhaps more reasonably: write the core of your application in Coq and have it expose a DSL for writing business logic atop this infallible core.
Xylakant 13y ago
Ruby != Rails. We do a lot of ruby, but practically no rails.
- eggnet 13y ago
  But rails is written in ruby. So it can't have security bugs, right?
  - chc 13y ago
    Observing that Ruby eliminates entire classes of bugs doesn't mean that Ruby eliminates all bugs; just that your attack surface is smaller.
    - mauvaisours 12y ago
      -smaller +different.
  - Xylakant 13y ago
    Sure it can and I'm not surprised it has. But if you're trying to point out flaws in ruby, at least use examples for flaws in ruby - not flaws in something written in ruby. It's not like web frameworks in other languages magically don't suffer from XSS injection attacks.
    - dllthomas 13y ago
      The issue at hand is a flaw in something written in C, though. I agree the point wasn't well made (is there any reason to think those errors would not have been made had the project been written in C?) but your objection isn't quite right.
      - Xylakant 13y ago
        The issue at hand is an error that is typical for C (unchecked out of bound memory access). It's a class of error that does usually not occur in other languages. The vulnerabilities in Rails were XSS vulnerabilities and an information leak - both classes of errors typically found in web application frameworks. The first is an example of an error made more common by the language design, the other an example of errors typical for a class of applications. There's a fundamental difference here. There's a ton of reasons to criticize ruby and it brings its own set of flaws and problems, some rooted in the language and some rooted in its ecosystem - but the given examples just show that web applications are hard to get right. That's why this is not "a point not well made" but rather "sorry, you're attacking a strawman here".
SparklingCotton 12y ago
There is a "just use X". If you code in a language where you can express the invariants in your code, and make the compiler check those invariants, then your code is immune to all of the vulnerabilities that we have seen in OpenSSL. The fact that these languages don't automatically do all my system administration tasks for me is not an argument against using them. http://en.wikipedia.org/wiki/Nirvana_fallacy#Perfect_solution_fallacy http://en.wikipedia.org/wiki/Nirvana_fallacy#Perfect_solutio...

by CCs 13y ago

lmm 13y ago

Rails does plenty of "make life easier for the programmer" things that I would expect to increase the risk of security issues. Do you have those kind of problems for e.g. Haskell?

deleted 13y ago
[deleted]
dtech 13y ago
Haskell problably has/would have the same kind of problems, but finding examples will be a lot harder in the absence of large well-used web platform à la RoR
- jerf 13y ago
  If you worked at it, you could create this problem in Haskell. However, it is in fact the case that Haskell would be, in its own way, screaming at you; your configuration (or whatever) parser takes in some text and then returns something of type "IO Configuration"... what is that IO doing there? You don't have to be very skilled in Haskell to stop right there and have a serious think about what's going on. And in the absence of IO, or some other really obviously wrong type signature, there isn't much malicious stuff you can do in the parser layer. You could still have a vulnerability by doing something wrong when given certain configurations, but there's not much we can do about straight-up bugs. Even a proof language will let you make straight-up errors, they'll just force you to deeply, profoundly make the error instead of superficially make it... but we humans are up to the task!
- einhverfr 12y ago
  Once you are doing functional programming a bunch of classes of problems including a bunch of classes of security problems go away. For example, here, if the guarantee of functional programming is that a given input leads to a given output and has no memory side effects, then your attack surface area is a lot, lot smaller.
- SparklingCotton 12y ago
  No it simply does not, because the language forces you to write pure functions. The type system invites you to express invariants. There are very fundamental connections between strong typing, program verification, and proofs. http://en.wikipedia.org/wiki/Curry-Howard_correspondence http://en.wikipedia.org/wiki/Curry-Howard_correspondence Thus, the argument that Haskell probably has the same, is simply false. There are large web platforms in Haskell. Yesod is probably the largest eco-system. It is clearly not as well used as RoR, but anyone can dig through large amounts of code to try to find these bugs. What Haskell has that everyone else has are bugs/misunderstandings in how protocols are implemented. Sometimes there can be fundamental bugs in the run-time-system. However, large classes of bugs are fundamentally less likely to appear than in less safe languages.
rickr 13y ago
Remember - Rails is a framework for webapps. Haskell is a language. You should be comparing ruby to haskell.

khafra 13y ago

Write everything in Coq.

tel 13y ago
Perhaps more reasonably: write the core of your application in Coq and have it expose a DSL for writing business logic atop this infallible core.

Xylakant 13y ago

Ruby != Rails. We do a lot of ruby, but practically no rails.

eggnet 13y ago
But rails is written in ruby. So it can't have security bugs, right?
- chc 13y ago
  Observing that Ruby eliminates entire classes of bugs doesn't mean that Ruby eliminates all bugs; just that your attack surface is smaller.
  - mauvaisours 12y ago
    -smaller +different.
- Xylakant 13y ago
  Sure it can and I'm not surprised it has. But if you're trying to point out flaws in ruby, at least use examples for flaws in ruby - not flaws in something written in ruby. It's not like web frameworks in other languages magically don't suffer from XSS injection attacks.
  - dllthomas 13y ago
    The issue at hand is a flaw in something written in C, though. I agree the point wasn't well made (is there any reason to think those errors would not have been made had the project been written in C?) but your objection isn't quite right.
    - Xylakant 13y ago
      The issue at hand is an error that is typical for C (unchecked out of bound memory access). It's a class of error that does usually not occur in other languages. The vulnerabilities in Rails were XSS vulnerabilities and an information leak - both classes of errors typically found in web application frameworks. The first is an example of an error made more common by the language design, the other an example of errors typical for a class of applications. There's a fundamental difference here. There's a ton of reasons to criticize ruby and it brings its own set of flaws and problems, some rooted in the language and some rooted in its ecosystem - but the given examples just show that web applications are hard to get right. That's why this is not "a point not well made" but rather "sorry, you're attacking a strawman here".

SparklingCotton 12y ago

There is a "just use X". If you code in a language where you can express the invariants in your code, and make the compiler check those invariants, then your code is immune to all of the vulnerabilities that we have seen in OpenSSL. The fact that these languages don't automatically do all my system administration tasks for me is not an argument against using them. http://en.wikipedia.org/wiki/Nirvana_fallacy#Perfect_solution_fallacy http://en.wikipedia.org/wiki/Nirvana_fallacy#Perfect_solutio...