4 ms·

Well that's not really a surprise. Perhaps the "Rails generation" will gain some engineering, product selection and QA skills now. There's a big reason banks

by meaty 14y ago

Well that's not really a surprise. Perhaps the "Rails generation" will gain some engineering, product selection and QA skills now. There's a big reason banks operate the way they do with the kit they do.

Xylakant 14y ago
Even given I must admit that this was a spectacularly stupid hole[1], I don't think your point is valid. It's not like other frameworks in other languages don't have similar issues [2]. Rails is for what it does well engineered, well tested and using it for what it's intended is usually a solid choice. Rails enables and pushes testing on all levels, thus improving quality of all rails apps that follow the lead. You can argue that rails is not a good fit for a lot of use cases, but that's a completely different argument - and one I usually agree with - but all in all rails and its ecosystem pushes exactly the values that you say are missing. [1] Auto-Unmarshalling yaml in xml, seriously? Who wants yaml in xml? [2] I'm sorry to single out spring here, but this is a nice example since it's the same kind of attack: Instatiation of an arbitrary class, in this case by modifying the class loader and loading the class from a remote server: http://support.springsource.com/security/cve-2010-1622 http://support.springsource.com/security/cve-2010-1622
- amalag 14y ago
  As a Rails developer myself, it is really embarrassing to admit that all Rails apps in the last few years have been completely and totally vulnerable. The good point that it was discovered by security researchers without a known exploit is good, but we don't know if it was previously exploited without anyone's knowledge. Maybe there were smart pen testers who were routinely getting in to Rails apps without anyone's knowledge for years.
  - Xylakant 14y ago
    I completely agree: It's a stupid bug that lingered long in the codebase, probably because it was hidden in an obscure feature that nobody knew about or used. It's embarrassing, but I bet that pretty much every larger framework out there had a remote code execution bug[1]. Still, it's wrong to point at it and say "that's an engineering or QA bug that's symptomatic for the rails bunch." I'm not a rails friend, but the response showed that the rails developers take security and QA serious. Patches and workarounds were released not only for the supported versions, but also for older, long-dead releases. [1] Sinatra didn't, but that's < 1000 LOC.
    - btilly 14y ago
      I bet that pretty much every larger framework out there had a remote code execution bug[1]. I would gladly take the other side of that bet. A decade ago I was working on a site using Perl/Mason/Apache. When we were bought by eBay, we were put through a thorough pen test. The ONLY security hole they identified as needing fixing was a redirect that could redirect to any URL anywhere. (The people testing us were shocked - they had never before seen that few problems.) To the best of my knowledge, no holes have been discovered in that architecture in the following decade either. (Looking through Apache vulnerabilities, there have been a couple of remote code exploits. But not on all platforms, and we turned off every feature we didn't need.) If you take the attitude up front that you won't have magic, this kind of bug doesn't tend to slip in. If you take the attitude that there will be a lot of magic, then this kind of bug does slip in.
      - Xylakant 14y ago
        > I would gladly take the other side of that bet. You admit that the framework you used had a couple of exploits and you were not affected because you turned of all features that you didn't need. The current rails vulnerability does not affect you if you turned off all features you didn't need. Same argument. So we have a hole in Mason, I already cited one in Spring, someone else cited one in .NET http://news.ycombinator.com/item?id=5043839 http://news.ycombinator.com/item?id=5043839.
        btilly 14y ago
        Not the framework, the Apache webserver. I am not aware that there has ever been a hole in Mason, and I would be surprised if there was.
- meaty 14y ago
  Bullshit. Rails pushes low time to market. That is all. Its built with precisely no engineering design or quality control on top of a poorly specified rickety language in a community of hype. However, my original generalizes the problem as a human issue which is where the real problem is: Did they do a risk analysis on rails - no Did they verify their architecture - no Did they perform input/type checking - no (sorry but statically typed languages win here) Did they act responsibly - no Would you trust them with your cash? Probably not then. This is the opposite of banks who have multiple layers of security to prevent all the associated risks of the business. Would a bank run their OLTP on rails? Hell no, because they did the risk analysis above, which is my point.
  - phillmv 14y ago
    >Did they do a risk analysis on rails - no Actually, this bug was discovered precisely because people began to perform a more in depth analysis. >Did they perform input/type checking - no (sorry but statically typed languages win here) LOL. It's 2013. Can we stop having this preposterous argument?
    - meaty 14y ago
      Perhaps they should have done this up front, you know as part of the engineering, hence my point. Stopping and thinking for a bit usually covers these problems. I've read a huge chunk of the rails framework source code and it certainly used to be a pretty amateur piece of kit. The argument is definitely not preposterous. Are you saying guarding against bad inputs and enforcing type is bad? A language which uses no type inference has less assumptions therefore is likely to be less error prone. I've proven this hundreds of times over the last 30 years of writing code in things from communications electronics to financial quotation platforms.
      - phillmv 14y ago
        >Perhaps they should have done this up front, you know as part of the engineering, hence my point. And you know what, I have a feeling they did have multiple people looking over the code, and it's been vigorously refactored over the years. Rails 3 is a somewhat different beast from Rails 2. Careful auditing reduces bugs but does not eliminate them. Crowing about "proper engineering" is very nice but is somewhat farcical given the state of the art in the industry. >Are you saying guarding against bad inputs and enforcing type is bad? No. Of course you guard against bad inputs. But that's wholly separate from enforcing the type of the objects. And it's not like people are eval()ing stuff willy-nilly.
- bdcravens 14y ago
  I don't think "Rails generation" means only Rails. I think the idea is that we're so dependent on frameworks these days, there are massive pieces of our application that we have no clue how they work, and worse, we trust the framework authors implicitly. More and more we're seeing the downfalls of this. As Rails is essentially the best known and most deployed, hence the name. Think about it: for most apps, probably 95% of your code is a framework that you didn't write. When this is criticized, the response is typically "open source unicorns! speak no more!" Moreover, there seems to be a different level of forgiveness just because it's open source. If ASP.NET WebForms had the same level of security holes in the past years as Rails ... just wow. I love frameworks, and I think an average team would on the whole write less secure code than an open source framework would. If we want maximum transparency into our code, we'd go back to CGI written in C, but our productivity would tank, and looking back, the boom of recent years never would have happened. However, we need a different attitude. Let's be honest: the arguments about open source are mostly a lie. Yeah, I went there. No, I'm not advocating closed source. Too many hang their hat on the ideals of open source. We're not talking ideals. We're talking rubber meets the road, cash leaves the bank reality. "Anyone can view the source - many eyeballs makes it more secure." The truth is, there aren't that many eyeballs. How many download, or (for the real technology ninjas) git clone, and trust what they're working with (whether app or framework) by a faith that rivals any religious organization? As an industry, we need to read more code. We need to push back against the Barnes and Noble developer, the one who paid $29 for a book and now calls themselves a developer because they finished it front to back. Not everyone needs to be a senior engineer, but we have too many with that title after 3 years of building framework apps who couldn't code their way out of a CS101 class if they had Donald Knuth and Dennis Ritchie as their personal tutors. This is pure supposition, but I think if at least 10% of those who used Rails read Rails, it'd be far more secure.
  - phillmv 14y ago
    > If ASP.NET WebForms had the same level of security holes in the past years as Rails ... just wow. That's a joke, right? https://www.google.ca/search?q=asp.net+remote+code&oq=asp.net+remote+code&sugexp=chrome,mod=11&sourceid=chrome&ie=UTF-8#hl=en&safe=off&tbo=d&sclient=psy-ab&q=.net+security+bulletin+critical+allow+remote+code&oq=.net+security+bulletin+critical+allow+remote+code&gs_l=serp.3..33i21.9746.12285.3.12409.18.18.0.0.0.0.190.2125.9j9.18.0.les%3B..0.0...1c.1.XgrZJUHpOhY&pbx=1&bav=on.2,or.r_gc.r_pw.r_qf.&bvm=bv.1357700187,d.b2I&fp=786683f34c375fc3&biw=1276&bih=683 https://www.google.ca/search?q=asp.net+remote+code&oq=as... >we trust the framework authors implicitly You want to export your common web app code to a framework for all the same reasons you don't want to write your own crypto libraries - the more people look at it the safer it is. Far more damage has been done to the web from people not using a good ORM or a toolkit that escapes your view layer against XSS, or forgot to add request forgery protection.

by meaty 14y ago

Xylakant 14y ago

Even given I must admit that this was a spectacularly stupid hole[1], I don't think your point is valid. It's not like other frameworks in other languages don't have similar issues [2]. Rails is for what it does well engineered, well tested and using it for what it's intended is usually a solid choice. Rails enables and pushes testing on all levels, thus improving quality of all rails apps that follow the lead. You can argue that rails is not a good fit for a lot of use cases, but that's a completely different argument - and one I usually agree with - but all in all rails and its ecosystem pushes exactly the values that you say are missing. [1] Auto-Unmarshalling yaml in xml, seriously? Who wants yaml in xml? [2] I'm sorry to single out spring here, but this is a nice example since it's the same kind of attack: Instatiation of an arbitrary class, in this case by modifying the class loader and loading the class from a remote server: http://support.springsource.com/security/cve-2010-1622 http://support.springsource.com/security/cve-2010-1622

amalag 14y ago
As a Rails developer myself, it is really embarrassing to admit that all Rails apps in the last few years have been completely and totally vulnerable. The good point that it was discovered by security researchers without a known exploit is good, but we don't know if it was previously exploited without anyone's knowledge. Maybe there were smart pen testers who were routinely getting in to Rails apps without anyone's knowledge for years.
- Xylakant 14y ago
  I completely agree: It's a stupid bug that lingered long in the codebase, probably because it was hidden in an obscure feature that nobody knew about or used. It's embarrassing, but I bet that pretty much every larger framework out there had a remote code execution bug[1]. Still, it's wrong to point at it and say "that's an engineering or QA bug that's symptomatic for the rails bunch." I'm not a rails friend, but the response showed that the rails developers take security and QA serious. Patches and workarounds were released not only for the supported versions, but also for older, long-dead releases. [1] Sinatra didn't, but that's < 1000 LOC.
  - btilly 14y ago
    I bet that pretty much every larger framework out there had a remote code execution bug[1]. I would gladly take the other side of that bet. A decade ago I was working on a site using Perl/Mason/Apache. When we were bought by eBay, we were put through a thorough pen test. The ONLY security hole they identified as needing fixing was a redirect that could redirect to any URL anywhere. (The people testing us were shocked - they had never before seen that few problems.) To the best of my knowledge, no holes have been discovered in that architecture in the following decade either. (Looking through Apache vulnerabilities, there have been a couple of remote code exploits. But not on all platforms, and we turned off every feature we didn't need.) If you take the attitude up front that you won't have magic, this kind of bug doesn't tend to slip in. If you take the attitude that there will be a lot of magic, then this kind of bug does slip in.
    - Xylakant 14y ago
      > I would gladly take the other side of that bet. You admit that the framework you used had a couple of exploits and you were not affected because you turned of all features that you didn't need. The current rails vulnerability does not affect you if you turned off all features you didn't need. Same argument. So we have a hole in Mason, I already cited one in Spring, someone else cited one in .NET http://news.ycombinator.com/item?id=5043839 http://news.ycombinator.com/item?id=5043839.
      - btilly 14y ago
        Not the framework, the Apache webserver. I am not aware that there has ever been a hole in Mason, and I would be surprised if there was.
meaty 14y ago
Bullshit. Rails pushes low time to market. That is all. Its built with precisely no engineering design or quality control on top of a poorly specified rickety language in a community of hype. However, my original generalizes the problem as a human issue which is where the real problem is: Did they do a risk analysis on rails - no Did they verify their architecture - no Did they perform input/type checking - no (sorry but statically typed languages win here) Did they act responsibly - no Would you trust them with your cash? Probably not then. This is the opposite of banks who have multiple layers of security to prevent all the associated risks of the business. Would a bank run their OLTP on rails? Hell no, because they did the risk analysis above, which is my point.
- phillmv 14y ago
  >Did they do a risk analysis on rails - no Actually, this bug was discovered precisely because people began to perform a more in depth analysis. >Did they perform input/type checking - no (sorry but statically typed languages win here) LOL. It's 2013. Can we stop having this preposterous argument?
  - meaty 14y ago
    Perhaps they should have done this up front, you know as part of the engineering, hence my point. Stopping and thinking for a bit usually covers these problems. I've read a huge chunk of the rails framework source code and it certainly used to be a pretty amateur piece of kit. The argument is definitely not preposterous. Are you saying guarding against bad inputs and enforcing type is bad? A language which uses no type inference has less assumptions therefore is likely to be less error prone. I've proven this hundreds of times over the last 30 years of writing code in things from communications electronics to financial quotation platforms.
    - phillmv 14y ago
      >Perhaps they should have done this up front, you know as part of the engineering, hence my point. And you know what, I have a feeling they did have multiple people looking over the code, and it's been vigorously refactored over the years. Rails 3 is a somewhat different beast from Rails 2. Careful auditing reduces bugs but does not eliminate them. Crowing about "proper engineering" is very nice but is somewhat farcical given the state of the art in the industry. >Are you saying guarding against bad inputs and enforcing type is bad? No. Of course you guard against bad inputs. But that's wholly separate from enforcing the type of the objects. And it's not like people are eval()ing stuff willy-nilly.
bdcravens 14y ago
I don't think "Rails generation" means only Rails. I think the idea is that we're so dependent on frameworks these days, there are massive pieces of our application that we have no clue how they work, and worse, we trust the framework authors implicitly. More and more we're seeing the downfalls of this. As Rails is essentially the best known and most deployed, hence the name. Think about it: for most apps, probably 95% of your code is a framework that you didn't write. When this is criticized, the response is typically "open source unicorns! speak no more!" Moreover, there seems to be a different level of forgiveness just because it's open source. If ASP.NET WebForms had the same level of security holes in the past years as Rails ... just wow. I love frameworks, and I think an average team would on the whole write less secure code than an open source framework would. If we want maximum transparency into our code, we'd go back to CGI written in C, but our productivity would tank, and looking back, the boom of recent years never would have happened. However, we need a different attitude. Let's be honest: the arguments about open source are mostly a lie. Yeah, I went there. No, I'm not advocating closed source. Too many hang their hat on the ideals of open source. We're not talking ideals. We're talking rubber meets the road, cash leaves the bank reality. "Anyone can view the source - many eyeballs makes it more secure." The truth is, there aren't that many eyeballs. How many download, or (for the real technology ninjas) git clone, and trust what they're working with (whether app or framework) by a faith that rivals any religious organization? As an industry, we need to read more code. We need to push back against the Barnes and Noble developer, the one who paid $29 for a book and now calls themselves a developer because they finished it front to back. Not everyone needs to be a senior engineer, but we have too many with that title after 3 years of building framework apps who couldn't code their way out of a CS101 class if they had Donald Knuth and Dennis Ritchie as their personal tutors. This is pure supposition, but I think if at least 10% of those who used Rails read Rails, it'd be far more secure.
- phillmv 14y ago
  > If ASP.NET WebForms had the same level of security holes in the past years as Rails ... just wow. That's a joke, right? https://www.google.ca/search?q=asp.net+remote+code&oq=asp.net+remote+code&sugexp=chrome,mod=11&sourceid=chrome&ie=UTF-8#hl=en&safe=off&tbo=d&sclient=psy-ab&q=.net+security+bulletin+critical+allow+remote+code&oq=.net+security+bulletin+critical+allow+remote+code&gs_l=serp.3..33i21.9746.12285.3.12409.18.18.0.0.0.0.190.2125.9j9.18.0.les%3B..0.0...1c.1.XgrZJUHpOhY&pbx=1&bav=on.2,or.r_gc.r_pw.r_qf.&bvm=bv.1357700187,d.b2I&fp=786683f34c375fc3&biw=1276&bih=683 https://www.google.ca/search?q=asp.net+remote+code&oq=as... >we trust the framework authors implicitly You want to export your common web app code to a framework for all the same reasons you don't want to write your own crypto libraries - the more people look at it the safer it is. Far more damage has been done to the web from people not using a good ORM or a toolkit that escapes your view layer against XSS, or forgot to add request forgery protection.