8 ms·

The "everybody has bugs" response is intellectually dishonest. Yes, everybody has bugs, but most people's bugs aren't an intentional feature that a trained monk

The "everybody has bugs" response is intellectually dishonest. Yes, everybody has bugs, but most people's bugs aren't an intentional feature that a trained monkey ought to have known was a bad idea. - Someone implemented a YAML parser that executed code. This should have been obviously wrong to them, but it wasn't. - Thousands of ostensible developers used this parser, saw the fact that it could deserialize more than just data, and never said "Oh dear, that's a massive red flag". - The bug in the YAML parser was reported and the author of the YAML library genuinely couldn't figure out why this mattered or how it could be bad. - The issue was reported to RubyGems multiple times and they did nothing. This isn't the same thing as a complex and accidental bug that even careful engineers have difficulty avoiding, after they've already taken steps to reduce the failure surface of their code through privilege separation, high-level languages/libraries, etc. This is systemic engineering incompetence that apparently pervades an entire language community, and this is the tipping point where other people start looking for these issues.

chimeracoder 14y ago
> The bug in the YAML parser was reported and the author of the YAML library genuinely couldn't figure out why this mattered or how it could be bad. Is that seriously what happened? It sounds oddly similar to the Rails issue from about a year ago (the one in which the reporter was able to commit to master on Github), even though I believe that was a separate set of developers altogether. If so, then that might suggest a larger community/cultural issue, which makes me wonder what other exploits exist but haven't been reported (publicly) yet...
- purephase 14y ago
  Different issue altogether. It was mass-assignment wherein the default Rails config did not have the whitelist enabled by default. The howto is here: http://homakov.blogspot.ca/2012/03/how-to.html http://homakov.blogspot.ca/2012/03/how-to.html
  - chimeracoder 14y ago
    I know it was a different vulnerability - I was asking more whether the same developer(s) was/were responsible, since this seems to be a comment pattern that I'm hearing with regards to the initial response to the vulnerabilities.
  - tomjen3 14y ago
    Actually it is the same issue as basically all other security issues in web programming (attack on crypto aside): Failure to blacklist non-conforming input. Really, it is that simple and that complicated.
    - dos1 14y ago
      Wouldn't whitelisting conforming input be a better approach? I realize it may be more difficult, but wouldn't that be more secure? Edit: I'm genuinely interested - I always try and whitelist things when I'm building software. Although I have next to no background when it comes to security in particular.
      - purephase 14y ago
        Whitelisting is what Rails did to get around the mass assignment issue. It was solved for awhile, it just was not the default configuration setting. Whitelisting is what the rubygems folks are doing to work around this problem until a better implementation is put in-place in the YAML parser. Generally, it is a better solution but it is more difficult and can break a lot of dependencies if not implemented correctly.
      - tomjen3 14y ago
        Stupid me. I meant to write whitelisting. Yes, you are absolutely right.
- pifflesnort 14y ago
  > Is that seriously what happened? Surprisingly, yes: https://github.com/tenderlove/psych/issues/119 https://github.com/tenderlove/psych/issues/119 And the RubyGems folks are trying to handle this with whitelisting specific classes that the YAML parsing will still be allowed to instantiate: https://github.com/rubygems/rubygems.org/pull/516/files https://github.com/rubygems/rubygems.org/pull/516/files
  - purephase 14y ago
    As a temporary workaround until Psych is updated. At least that's how I read it. We can either sit around throwing stones at them or pull up our sleeves and help. I'm not sure what there is to gain with the former.
    - tomjen3 14y ago
      Rails needs to die. It is super nice to code in (for a certain class of problems, ie. CRUD apps) and the language is awesome but it is too big and insecure to use.
      - jroes 14y ago
        I'm willing to bet if you put someone like benmmurphy, ptacek, or homakov in your codebase he'll have you begging for a web framework in hours.
        newman314 14y ago
        I wonder if various companies pooled money for a comprehensive audit of rails by ptacek etc., one would think that's a win-win for all.
        thibaut_barrere 14y ago
        I wondered exactly the same thing, a security-chase kickstarter or similar.
      - 14y ago
- homakov 14y ago
  > It sounds oddly similar to the Rails issue from about a year ago (the one in which the reporter was able to commit to master on Github) Hey, yes, yaml bug is _very_ similar. Whitelist is better than no list at all
jerf 14y ago
"Yes, everybody has bugs, but most people's bugs aren't an intentional feature that a trained monkey ought to have known was a bad idea." First, given how many times I've seen a deserialization library "helpfully" allow you to deserialize into arbitrary objects in a language that is sufficiently dynamic to turn this into arbitrary code execution, evidence suggests this is not an accurate summary. I'd like to see "Don't deserialize into arbitrary objects" become General Programming Wisdom, but it is not there yet. It's not like we live in a world where XSS is rare or anything anyhow. The general level of programming aptitude is low here. That's bad, regrettable, something I'd love to see change and love to help change, but it is also something we have to deal with as a brute fact. Secondly, there's still the points of A: even if you don't use Ruby on Rails, your life may still be adversely affected by the Severity: Apocalyptic bug, and B: what are you going to do when the Severity: Apocalyptic bug is located in your codebase? And that's putting aside the obvious matters of what to do if you use Ruby on Rails and this was your codebase. The exact details of today's Severity: Apolalyptic bug are less relevant than you may initially think. Go back and read the piece, strike every sentence that contains "YAML". It's still a very important piece. At which point a re-quoting of my favorite line in the piece is probably called for: "If you believe in karma or capricious supernatural agencies which have an active interest in balancing accounts, chortling about Ruby on Rails developers suffering at the moment would be about as well-advised as a classical Roman cursing the gods during a thunderstorm while tapdancing naked in the pool on top of a temple consecrated to Zeus while holding nothing but a bronze rod used for making obscene gestures towards the heavens." Epic.
- ScottBurson 14y ago
  > I'd like to see "Don't deserialize into arbitrary objects" become General Programming Wisdom, but it is not there yet. I think that's pifflesnort's point.
  - jerf 14y ago
    No, his point is that it already is and we can declare anybody who doesn't know to be worse than a "trained monkey". I say the evidence clearly shows that it is not widespread knowledge (IMHO "trained monkey" makes it sound like you could ask a normal college sophomore about this and get the correct response, which is just false, a lot of programmers don't even know what the term "serialization" means), and while it is a great goal we can not act as if it is already true.
patio11 14y ago
Any sufficiently advanced serialization standard will let you serialize/deserialize a wide variety of objects. When J2EE SOAP libraries are passing large amounts of XML back and forth over the wire, it is often going to get instantiated via calling a zero-argument constructor and then firing a bunch of setter methods. As J2EE has learned to its sorrow, there are some good choices for objects to allow people to deserialize and some not so good ones. http://wouter.coekaerts.be/2011/spring-vulnerabilities http://wouter.coekaerts.be/2011/spring-vulnerabilities If J2EE is a boring platform to you, pick your favorite and Google for a few variants. You'll find a serialization vulnerability. It's hard stuff, by nature. * The bug in the YAML parser was reported and the author of the YAML library genuinely couldn't figure out why this mattered or how it could be bad.* Do you have a citation for this? What particular bug in the parser are you referring to? The behavior which is being exploited is a fairly complicated interaction between the parser and client Rails code -- I banged my head against the wall trying to get code execution with Ruby 1.8.7's parser for over 12 hours, for example, without any luck unless I coded a too-stupid-to-be-real victim class. (It's my understanding that at least one security researcher has a way to make that happen, but that knowledge was hard won.)
- pifflesnort 14y ago
  > Any sufficiently advanced serialization standard ... it is often going to get instantiated via calling a zero-argument constructor and then firing a bunch of setter methods. Yes, this is always a bad idea. It's actually in a similar problem space as the constant stream of vulnerabilities in the Java security sandbox (eg, applets); all it takes is one mistake and you lose. And thus, people have been saying to turn off Java in the browser for 4+ years, and this is also why Spring shouldn't have implemented such code. > It's hard stuff, by nature. Which is why deserializing into executable code is a bad idea, by nature. I'd thought this was well established by now, but apparently it is not. > Do you have a citation for this? What particular bug in the parser are you referring to? http://github.com/tenderlove/psych/issues/119 http://github.com/tenderlove/psych/issues/119
  - jrochkind1 14y ago
    > Which is why deserializing into executable code is a bad idea, by nature. I'd thought this was well established by now, but apparently it is not I'm not sure that means anything. In an OO language, you are always de-serializing into objects, and objects are always 'executable code'. Hashes and Arrays are executable code too, right? The problem is actually when you allow de-serializing into _arbitrary_ objects of arbitrary classes, and some of those objects have dangerous side effects _just by being instantiated_, and/or have functionality that can turn into arbitrary code execution vector. (Hopefully Hash's and Array's don't). It is a problem, and it's probably fair to say that you should never have a de-serialization format that takes untrusted input and de-serializes to anyting but a small whitelisted set of classes/types. And that many have violated this, and not just in ruby. But if you can't even describe the problem/guidance clearly yourself, I think that rather belies your insistence that it's an obvious thing known by the standard competent programmer. (I am not ashamed to admit it was not obvious to me before these exploits. I think it was not obvious to a bunch of people who are in retrospect _claiming_ it was obvious to.).
SilasX 14y ago
>The issue was reported to RubyGems multiple times and they did nothing. Er, there would have been trouble on that end too ... http://news.ycombinator.com/item?id=5139583 http://news.ycombinator.com/item?id=5139583
NelsonMinar 14y ago
What is crazy to me is everyone has had this bug, and learned from it, and fixed it. Why has it taken so long for Rails? Java has this bug; you can't deserialize untrusted input without a lot of work. Python has this bug; you can't unpickle untrusted input. Bad Javascript JSON parsers that just call eval() have this bug. It's not a complicated concept; you can't treat untrusted user input as code to execute. How'd the YAML developers miss it?
- Spakman 14y ago
  Presumably they missed it the same way the developers of those other things you listed did. I can only assume they didn't know about these other problems when developing their YAML parsers. Of course, you could argue that developers should always be thinking about and searching for security related issues in whatever field they're working in, but that doesn't appear to be the norm at the moment.
- alexch 14y ago
  My analysis: layering. YAML doesn't in itself execute untrusted code, but it has a bunch of semi-experimental features most people don't know about or use, and one of those features (deserializing arbitrary classes) has a side effect that sets values on certain other classes -- not written by the people who wrote the YAML parser -- that then, often later on in their lifecycle, execute this untrusted code. I'm not saying this as an excuse -- I have long mistrusted YAML's blasé complexity, not to mention Rails' anarchic pass-HTTP-params-directly-into-the-DB pattern -- but as an explanation of how they missed it. Also, more than other communities, Ruby has a cultural gap between the people developing the language and core libraries and the people using it to write web apps and frameworks. Here's two good technical writeups of the exploit as it applies to Rails apps: http://blog.codeclimate.com/blog/2013/01/10/rails-remote-code-execution-vulnerability-explained/ http://blog.codeclimate.com/blog/2013/01/10/rails-remote-cod... http://ronin-ruby.github.com/blog/2013/01/09/rails-pocs.html http://ronin-ruby.github.com/blog/2013/01/09/rails-pocs.html
  - NelsonMinar 14y ago
    Thanks, the complexity and layering are presumably part of the problem. This reminds me of the old XML External Entity attack that keeps coming back because developers don't realize you can coerce most XML parsers to open arbitrary URLs. That's been affecting products that parse XML for 10 years now and still hasn't stopped and leads to ugly security holes (like in Adobe Reader). The root cause is XML is far too complex and has surprising features, in this case, entity definition by URL.
netshade 14y ago
Speaking to the first portion of your complaint, I remember coming across that particular feature of YAML years ago, and being surprised at how odd it was that it was present. I shrugged it off because (at the time), I considered YAML to be something that simply would not enter the serialize / deserialize phase of incoming requests. Ignorance of all the frameworks actions on my part, and further ignorance to not think of the security effects of that particular feature, certainly. I would presume that I am not the only in that situation. You're definitely right that the security reports should be handled better. I hope that this whole situation results in a better security culture in the Ruby community. Regarding your tone ("intellectually dishonest", "trained monkey", "systemic engineering incompetence pervades an entire language community"), it's a bit of hyperbole and active trolling. You are certainly right in many of your points, and you are certainly coming off as a jerk. It may not be as cathartic for you, but I'd suggest toning it down to "reasonable human being" level in the future.
- pifflesnort 14y ago
  > It may not be as cathartic for you, but I'd suggest toning it down to "reasonable human being" level in the future. The Rails community has exhibited such self-assured, self-promotional exuberance for so long (and continues to do so here), it feels necessary to rely on equivalently forceful and bellicose language to have a hope of countering the spin and marketing messaging. Case in point, the article seriously says, with a straight face: "They’re being found at breakneck pace right now precisely because they required substantial new security technology to actually exploit, and that new technology has unlocked an exciting new frontier in vulnerability research." Substantial new security technology? To claim that a well known vulnerability source -- parsers executing code -- involves not only substantial new technology, but is a new frontier in vulnerability research? This is pure marketing drivel intended to spin responsibility away from Ruby/Rails, because the problems are somehow advanced and new. This is not coming from some unknown corner of the community, but from a well-known entity with a significant voice.
  - netshade 14y ago
    I can understand your frustration with the community. I share this frustration at many times, because I feel that Rails / Ruby tends to value style over substance. I'll also raise an eyebrow at that particular sentence, though without spending much time looking into what's backing it I can only add that I too find that slightly incredulous. I definitely question your stated intent. Were you to "counter the spin and marketing messaging", would that reduce the number of vulnerable machines? Overall, reduce the number of people that use Ruby/Rails, if that is your intent? Given the number of comments you've made to that effect versus the number of folks using Ruby/Rails, I'd suggest you have a very long battle in front of you. Put another way, I perceive your tone as an exasperated, reactionary tone to a group that you happen not to like. If you are indeed trying to achieve some greater good here, I believe there's more effective ways you could achieve it. Otherwise, just tone it down in the future. You had good points, there's no need to insult people from an effectively unassailable position.
jarekr 14y ago
This is systemic engineering incompetence that apparently pervades an entire language community This is master level, "Captain Obvious"-style trolling, beyond me how this is the top comment in a place like HN.
jrochkind1 14y ago
> Someone implemented a YAML parser that executed code. This should have been obviously wrong to them, but it wasn't. Someone implemented a YAML parser that could serialize and de-serialize arbitrary objects referenced by class name. It was not obvious that this meant it 'executed code', let alone that this meant it could execute _arbitrary_ code, so long as there was a predictable class in the load path with certain characteristics, which there was in Rails. In retrospect it is obvious, but I think you over-estimate the obviousness without hindsight. It's always easy to say everyone should have known what nobody actually did but which everyone now does. As others have pointed out, an almost identical problem existed in Spring too (de-serializing arbitrary objects leads to arbitrary code execution). It wasn't obvious to them either. Maybe it _should_ have been obvious _after_ that happened -- but that vulnerability didn't get much publicity. Now that the YAML one has, maybe it hopefully WILL be obvious next time! Anyhow, that lack of obviousness applies to at least your first two points if not first three. It was not in fact obvious to most people that you could execute (arbitrary) code with YAML. If it was obvious to you, I wish you had spent more time trying to 'paul revere' it. > The issue was reported to RubyGems multiple times and they did nothing. Now, THAT part, yeah, that's a problem. I think 'multiple times' is 'two' (yeah, that is technically 'multiple'), and only over a week -- but that still indicates irresponsibility on rubygems.org maintainers part. A piece of infrastructure that, if compromised, can lead to compromise to almost all or rubydom -- that is scary, that needs a lot more responsibilty than it got. We're lucky the exploit was in fact publisizied rather than kept secret and exploited to inject an attack into the code of any ruby gem an attacker wanted -- except of course, we can't know for sure if it was or not.
deleted 14y ago
[deleted]
martinced 14y ago
"The "everybody has bugs" response is intellectually dishonest." Indeed. It's the "fallacy of gray". Nothing is black or white, hence everything is gray. Nothing is 100% secure, nothing is 100% insecure, hence everything is "semi-secure": it's bad, but not too bad, because every language / API / server can be attacked. You've effectively substituted a black/white dichotomy with something even worse: instead of having only two options (black or white), you now only have one: gray. It is probably one of the most intellectually dishonest logical fallacy of all times and we keep seeing it more and more. It's really concerning.

chimeracoder 14y ago

> The bug in the YAML parser was reported and the author of the YAML library genuinely couldn't figure out why this mattered or how it could be bad. Is that seriously what happened? It sounds oddly similar to the Rails issue from about a year ago (the one in which the reporter was able to commit to master on Github), even though I believe that was a separate set of developers altogether. If so, then that might suggest a larger community/cultural issue, which makes me wonder what other exploits exist but haven't been reported (publicly) yet...

purephase 14y ago
Different issue altogether. It was mass-assignment wherein the default Rails config did not have the whitelist enabled by default. The howto is here: http://homakov.blogspot.ca/2012/03/how-to.html http://homakov.blogspot.ca/2012/03/how-to.html
- chimeracoder 14y ago
  I know it was a different vulnerability - I was asking more whether the same developer(s) was/were responsible, since this seems to be a comment pattern that I'm hearing with regards to the initial response to the vulnerabilities.
- tomjen3 14y ago
  Actually it is the same issue as basically all other security issues in web programming (attack on crypto aside): Failure to blacklist non-conforming input. Really, it is that simple and that complicated.
  - dos1 14y ago
    Wouldn't whitelisting conforming input be a better approach? I realize it may be more difficult, but wouldn't that be more secure? Edit: I'm genuinely interested - I always try and whitelist things when I'm building software. Although I have next to no background when it comes to security in particular.
    - purephase 14y ago
      Whitelisting is what Rails did to get around the mass assignment issue. It was solved for awhile, it just was not the default configuration setting. Whitelisting is what the rubygems folks are doing to work around this problem until a better implementation is put in-place in the YAML parser. Generally, it is a better solution but it is more difficult and can break a lot of dependencies if not implemented correctly.
    - tomjen3 14y ago
      Stupid me. I meant to write whitelisting. Yes, you are absolutely right.
pifflesnort 14y ago
> Is that seriously what happened? Surprisingly, yes: https://github.com/tenderlove/psych/issues/119 https://github.com/tenderlove/psych/issues/119 And the RubyGems folks are trying to handle this with whitelisting specific classes that the YAML parsing will still be allowed to instantiate: https://github.com/rubygems/rubygems.org/pull/516/files https://github.com/rubygems/rubygems.org/pull/516/files
- purephase 14y ago
  As a temporary workaround until Psych is updated. At least that's how I read it. We can either sit around throwing stones at them or pull up our sleeves and help. I'm not sure what there is to gain with the former.
  - tomjen3 14y ago
    Rails needs to die. It is super nice to code in (for a certain class of problems, ie. CRUD apps) and the language is awesome but it is too big and insecure to use.
    - jroes 14y ago
      I'm willing to bet if you put someone like benmmurphy, ptacek, or homakov in your codebase he'll have you begging for a web framework in hours.
      - newman314 14y ago
        I wonder if various companies pooled money for a comprehensive audit of rails by ptacek etc., one would think that's a win-win for all.
        thibaut_barrere 14y ago
        I wondered exactly the same thing, a security-chase kickstarter or similar.
    - 14y ago
homakov 14y ago
> It sounds oddly similar to the Rails issue from about a year ago (the one in which the reporter was able to commit to master on Github) Hey, yes, yaml bug is _very_ similar. Whitelist is better than no list at all

jerf 14y ago

"Yes, everybody has bugs, but most people's bugs aren't an intentional feature that a trained monkey ought to have known was a bad idea." First, given how many times I've seen a deserialization library "helpfully" allow you to deserialize into arbitrary objects in a language that is sufficiently dynamic to turn this into arbitrary code execution, evidence suggests this is not an accurate summary. I'd like to see "Don't deserialize into arbitrary objects" become General Programming Wisdom, but it is not there yet. It's not like we live in a world where XSS is rare or anything anyhow. The general level of programming aptitude is low here. That's bad, regrettable, something I'd love to see change and love to help change, but it is also something we have to deal with as a brute fact. Secondly, there's still the points of A: even if you don't use Ruby on Rails, your life may still be adversely affected by the Severity: Apocalyptic bug, and B: what are you going to do when the Severity: Apocalyptic bug is located in your codebase? And that's putting aside the obvious matters of what to do if you use Ruby on Rails and this was your codebase. The exact details of today's Severity: Apolalyptic bug are less relevant than you may initially think. Go back and read the piece, strike every sentence that contains "YAML". It's still a very important piece. At which point a re-quoting of my favorite line in the piece is probably called for: "If you believe in karma or capricious supernatural agencies which have an active interest in balancing accounts, chortling about Ruby on Rails developers suffering at the moment would be about as well-advised as a classical Roman cursing the gods during a thunderstorm while tapdancing naked in the pool on top of a temple consecrated to Zeus while holding nothing but a bronze rod used for making obscene gestures towards the heavens." Epic.

ScottBurson 14y ago
> I'd like to see "Don't deserialize into arbitrary objects" become General Programming Wisdom, but it is not there yet. I think that's pifflesnort's point.
- jerf 14y ago
  No, his point is that it already is and we can declare anybody who doesn't know to be worse than a "trained monkey". I say the evidence clearly shows that it is not widespread knowledge (IMHO "trained monkey" makes it sound like you could ask a normal college sophomore about this and get the correct response, which is just false, a lot of programmers don't even know what the term "serialization" means), and while it is a great goal we can not act as if it is already true.

patio11 14y ago

Any sufficiently advanced serialization standard will let you serialize/deserialize a wide variety of objects. When J2EE SOAP libraries are passing large amounts of XML back and forth over the wire, it is often going to get instantiated via calling a zero-argument constructor and then firing a bunch of setter methods. As J2EE has learned to its sorrow, there are some good choices for objects to allow people to deserialize and some not so good ones. http://wouter.coekaerts.be/2011/spring-vulnerabilities http://wouter.coekaerts.be/2011/spring-vulnerabilities If J2EE is a boring platform to you, pick your favorite and Google for a few variants. You'll find a serialization vulnerability. It's hard stuff, by nature. * The bug in the YAML parser was reported and the author of the YAML library genuinely couldn't figure out why this mattered or how it could be bad.* Do you have a citation for this? What particular bug in the parser are you referring to? The behavior which is being exploited is a fairly complicated interaction between the parser and client Rails code -- I banged my head against the wall trying to get code execution with Ruby 1.8.7's parser for over 12 hours, for example, without any luck unless I coded a too-stupid-to-be-real victim class. (It's my understanding that at least one security researcher has a way to make that happen, but that knowledge was hard won.)

pifflesnort 14y ago
> Any sufficiently advanced serialization standard ... it is often going to get instantiated via calling a zero-argument constructor and then firing a bunch of setter methods. Yes, this is always a bad idea. It's actually in a similar problem space as the constant stream of vulnerabilities in the Java security sandbox (eg, applets); all it takes is one mistake and you lose. And thus, people have been saying to turn off Java in the browser for 4+ years, and this is also why Spring shouldn't have implemented such code. > It's hard stuff, by nature. Which is why deserializing into executable code is a bad idea, by nature. I'd thought this was well established by now, but apparently it is not. > Do you have a citation for this? What particular bug in the parser are you referring to? http://github.com/tenderlove/psych/issues/119 http://github.com/tenderlove/psych/issues/119
- jrochkind1 14y ago
  > Which is why deserializing into executable code is a bad idea, by nature. I'd thought this was well established by now, but apparently it is not I'm not sure that means anything. In an OO language, you are always de-serializing into objects, and objects are always 'executable code'. Hashes and Arrays are executable code too, right? The problem is actually when you allow de-serializing into _arbitrary_ objects of arbitrary classes, and some of those objects have dangerous side effects _just by being instantiated_, and/or have functionality that can turn into arbitrary code execution vector. (Hopefully Hash's and Array's don't). It is a problem, and it's probably fair to say that you should never have a de-serialization format that takes untrusted input and de-serializes to anyting but a small whitelisted set of classes/types. And that many have violated this, and not just in ruby. But if you can't even describe the problem/guidance clearly yourself, I think that rather belies your insistence that it's an obvious thing known by the standard competent programmer. (I am not ashamed to admit it was not obvious to me before these exploits. I think it was not obvious to a bunch of people who are in retrospect _claiming_ it was obvious to.).

SilasX 14y ago

>The issue was reported to RubyGems multiple times and they did nothing. Er, there would have been trouble on that end too ... http://news.ycombinator.com/item?id=5139583 http://news.ycombinator.com/item?id=5139583

NelsonMinar 14y ago

What is crazy to me is everyone has had this bug, and learned from it, and fixed it. Why has it taken so long for Rails? Java has this bug; you can't deserialize untrusted input without a lot of work. Python has this bug; you can't unpickle untrusted input. Bad Javascript JSON parsers that just call eval() have this bug. It's not a complicated concept; you can't treat untrusted user input as code to execute. How'd the YAML developers miss it?

Spakman 14y ago
Presumably they missed it the same way the developers of those other things you listed did. I can only assume they didn't know about these other problems when developing their YAML parsers. Of course, you could argue that developers should always be thinking about and searching for security related issues in whatever field they're working in, but that doesn't appear to be the norm at the moment.
alexch 14y ago
My analysis: layering. YAML doesn't in itself execute untrusted code, but it has a bunch of semi-experimental features most people don't know about or use, and one of those features (deserializing arbitrary classes) has a side effect that sets values on certain other classes -- not written by the people who wrote the YAML parser -- that then, often later on in their lifecycle, execute this untrusted code. I'm not saying this as an excuse -- I have long mistrusted YAML's blasé complexity, not to mention Rails' anarchic pass-HTTP-params-directly-into-the-DB pattern -- but as an explanation of how they missed it. Also, more than other communities, Ruby has a cultural gap between the people developing the language and core libraries and the people using it to write web apps and frameworks. Here's two good technical writeups of the exploit as it applies to Rails apps: http://blog.codeclimate.com/blog/2013/01/10/rails-remote-code-execution-vulnerability-explained/ http://blog.codeclimate.com/blog/2013/01/10/rails-remote-cod... http://ronin-ruby.github.com/blog/2013/01/09/rails-pocs.html http://ronin-ruby.github.com/blog/2013/01/09/rails-pocs.html
- NelsonMinar 14y ago
  Thanks, the complexity and layering are presumably part of the problem. This reminds me of the old XML External Entity attack that keeps coming back because developers don't realize you can coerce most XML parsers to open arbitrary URLs. That's been affecting products that parse XML for 10 years now and still hasn't stopped and leads to ugly security holes (like in Adobe Reader). The root cause is XML is far too complex and has surprising features, in this case, entity definition by URL.

netshade 14y ago

Speaking to the first portion of your complaint, I remember coming across that particular feature of YAML years ago, and being surprised at how odd it was that it was present. I shrugged it off because (at the time), I considered YAML to be something that simply would not enter the serialize / deserialize phase of incoming requests. Ignorance of all the frameworks actions on my part, and further ignorance to not think of the security effects of that particular feature, certainly. I would presume that I am not the only in that situation. You're definitely right that the security reports should be handled better. I hope that this whole situation results in a better security culture in the Ruby community. Regarding your tone ("intellectually dishonest", "trained monkey", "systemic engineering incompetence pervades an entire language community"), it's a bit of hyperbole and active trolling. You are certainly right in many of your points, and you are certainly coming off as a jerk. It may not be as cathartic for you, but I'd suggest toning it down to "reasonable human being" level in the future.

pifflesnort 14y ago
> It may not be as cathartic for you, but I'd suggest toning it down to "reasonable human being" level in the future. The Rails community has exhibited such self-assured, self-promotional exuberance for so long (and continues to do so here), it feels necessary to rely on equivalently forceful and bellicose language to have a hope of countering the spin and marketing messaging. Case in point, the article seriously says, with a straight face: "They’re being found at breakneck pace right now precisely because they required substantial new security technology to actually exploit, and that new technology has unlocked an exciting new frontier in vulnerability research." Substantial new security technology? To claim that a well known vulnerability source -- parsers executing code -- involves not only substantial new technology, but is a new frontier in vulnerability research? This is pure marketing drivel intended to spin responsibility away from Ruby/Rails, because the problems are somehow advanced and new. This is not coming from some unknown corner of the community, but from a well-known entity with a significant voice.
- netshade 14y ago
  I can understand your frustration with the community. I share this frustration at many times, because I feel that Rails / Ruby tends to value style over substance. I'll also raise an eyebrow at that particular sentence, though without spending much time looking into what's backing it I can only add that I too find that slightly incredulous. I definitely question your stated intent. Were you to "counter the spin and marketing messaging", would that reduce the number of vulnerable machines? Overall, reduce the number of people that use Ruby/Rails, if that is your intent? Given the number of comments you've made to that effect versus the number of folks using Ruby/Rails, I'd suggest you have a very long battle in front of you. Put another way, I perceive your tone as an exasperated, reactionary tone to a group that you happen not to like. If you are indeed trying to achieve some greater good here, I believe there's more effective ways you could achieve it. Otherwise, just tone it down in the future. You had good points, there's no need to insult people from an effectively unassailable position.

jarekr 14y ago

This is systemic engineering incompetence that apparently pervades an entire language community This is master level, "Captain Obvious"-style trolling, beyond me how this is the top comment in a place like HN.

jrochkind1 14y ago

> Someone implemented a YAML parser that executed code. This should have been obviously wrong to them, but it wasn't. Someone implemented a YAML parser that could serialize and de-serialize arbitrary objects referenced by class name. It was not obvious that this meant it 'executed code', let alone that this meant it could execute _arbitrary_ code, so long as there was a predictable class in the load path with certain characteristics, which there was in Rails. In retrospect it is obvious, but I think you over-estimate the obviousness without hindsight. It's always easy to say everyone should have known what nobody actually did but which everyone now does. As others have pointed out, an almost identical problem existed in Spring too (de-serializing arbitrary objects leads to arbitrary code execution). It wasn't obvious to them either. Maybe it _should_ have been obvious _after_ that happened -- but that vulnerability didn't get much publicity. Now that the YAML one has, maybe it hopefully WILL be obvious next time! Anyhow, that lack of obviousness applies to at least your first two points if not first three. It was not in fact obvious to most people that you could execute (arbitrary) code with YAML. If it was obvious to you, I wish you had spent more time trying to 'paul revere' it. > The issue was reported to RubyGems multiple times and they did nothing. Now, THAT part, yeah, that's a problem. I think 'multiple times' is 'two' (yeah, that is technically 'multiple'), and only over a week -- but that still indicates irresponsibility on rubygems.org maintainers part. A piece of infrastructure that, if compromised, can lead to compromise to almost all or rubydom -- that is scary, that needs a lot more responsibilty than it got. We're lucky the exploit was in fact publisizied rather than kept secret and exploited to inject an attack into the code of any ruby gem an attacker wanted -- except of course, we can't know for sure if it was or not.

deleted 14y ago

[deleted]

martinced 14y ago

"The "everybody has bugs" response is intellectually dishonest." Indeed. It's the "fallacy of gray". Nothing is black or white, hence everything is gray. Nothing is 100% secure, nothing is 100% insecure, hence everything is "semi-secure": it's bad, but not too bad, because every language / API / server can be attacked. You've effectively substituted a black/white dichotomy with something even worse: instead of having only two options (black or white), you now only have one: gray. It is probably one of the most intellectually dishonest logical fallacy of all times and we keep seeing it more and more. It's really concerning.