3 ms·

In such cases I'd normally apply Hanlon's razor ( https://en.wikipedia.org/wiki/Hanlon%27s_razor https://en.wikipedia.org/wiki/Hanlon%27s_razor ) but this secur

In such cases I'd normally apply Hanlon's razor ( https://en.wikipedia.org/wiki/Hanlon%27s_razor https://en.wikipedia.org/wiki/Hanlon%27s_razor ) but this security gap is really huge and rather obvious if you have an informed look at the code. So this is one of the cases where I'd personally would not be surprised if in the far future someone admits on their death bed that malice was involved.

jerf 4y ago
This particular bug has manifested in many places now, and in all those cases I find it plausible that it was a confluence of several independent teams (as in, not even working on the same code) adding features until, whoops, it turns out the combination is catastrophic. You find it obvious after the fact, but I don't think it is always obvious at the time. It's really easy for someone to see a feature like "interpolate strings better than ever" in their string library, and say to themselves, "Hey, that sounds good, let's turn it on!" without realizing that "better than ever" means "with arbitrary lookup from a string into a class of some sort", and then chain a few things together and hey presto you've got an arbitrary code execution vulnerability. I personally think allowing arbitrary string -> class lookup for all classes in the runtime is automatically a security code smell at best if not outright antipattern, but I don't think this is at all well understood yet. (While the general pattern is hard to avoid, you should have to register all classes/structs/values/whatever you want to automatically load from somehow. This prevents things like "I can use the OS object to execute arbitrary shell code" from automatically and unexpectedly creeping in.) Dynamic languages are all but based on such a capability, with their "eval" support. It's probably still going to be decades before this is generally understood "programmer wisdom", partially because the particular confluence of features that enables this bug is not common. It's just that when it does happen, it's catastrophic. But it's not actually that common.
- brazzy 4y ago
  >I personally think allowing arbitrary string -> class lookup for all classes in the runtime is automatically a security code smell at best if not outright antipattern, but I don't think this is at all well understood yet. Spot on. Case in point: the maintainer of snakeyaml furiously arguing that a similar vulnerability in his code is the fault of absolutely everything (client code, any code that can be used as a deserialization gadget, "low quality tooling") except his code: https://bitbucket.org/snakeyaml/snakeyaml/issues/561/cve-2022-1471-vulnerability-in https://bitbucket.org/snakeyaml/snakeyaml/issues/561/cve-202...
  - richbell 4y ago
    > It only concludes that a YAML may execute code. This is *intentional* - this is why people use YAML (otherwise they may use JSON) ... > 100% of the application which use SnakeYAML do not parse data from untrusted sources. Wow, what a trainwreck of a thread. I don't know Jonathan but I would love to buy him a beer. Thank you for sharing. ;)
  - nucleardog 4y ago
    I’m so confused about how many times it’s reiterated that _no one_ is parsing untrusted YAML with the library. It’s so unlikely as to be laughable. Then later when someone says they are, he doubles down saying that parsing arbitrary YAML provided from people on the internet isn’t parsing “untrusted” YAML because they’re authenticated. Apparently it’s reasonable that anyone that signs up for a SaaS service gets code execution privileges on the prod infrastructure? I’m pretty sure that thread had me shaking my head hard enough to give me a concussion.

jerf 4y ago

This particular bug has manifested in many places now, and in all those cases I find it plausible that it was a confluence of several independent teams (as in, not even working on the same code) adding features until, whoops, it turns out the combination is catastrophic. You find it obvious after the fact, but I don't think it is always obvious at the time. It's really easy for someone to see a feature like "interpolate strings better than ever" in their string library, and say to themselves, "Hey, that sounds good, let's turn it on!" without realizing that "better than ever" means "with arbitrary lookup from a string into a class of some sort", and then chain a few things together and hey presto you've got an arbitrary code execution vulnerability. I personally think allowing arbitrary string -> class lookup for all classes in the runtime is automatically a security code smell at best if not outright antipattern, but I don't think this is at all well understood yet. (While the general pattern is hard to avoid, you should have to register all classes/structs/values/whatever you want to automatically load from somehow. This prevents things like "I can use the OS object to execute arbitrary shell code" from automatically and unexpectedly creeping in.) Dynamic languages are all but based on such a capability, with their "eval" support. It's probably still going to be decades before this is generally understood "programmer wisdom", partially because the particular confluence of features that enables this bug is not common. It's just that when it does happen, it's catastrophic. But it's not actually that common.

brazzy 4y ago
>I personally think allowing arbitrary string -> class lookup for all classes in the runtime is automatically a security code smell at best if not outright antipattern, but I don't think this is at all well understood yet. Spot on. Case in point: the maintainer of snakeyaml furiously arguing that a similar vulnerability in his code is the fault of absolutely everything (client code, any code that can be used as a deserialization gadget, "low quality tooling") except his code: https://bitbucket.org/snakeyaml/snakeyaml/issues/561/cve-2022-1471-vulnerability-in https://bitbucket.org/snakeyaml/snakeyaml/issues/561/cve-202...
- richbell 4y ago
  > It only concludes that a YAML may execute code. This is *intentional* - this is why people use YAML (otherwise they may use JSON) ... > 100% of the application which use SnakeYAML do not parse data from untrusted sources. Wow, what a trainwreck of a thread. I don't know Jonathan but I would love to buy him a beer. Thank you for sharing. ;)
- nucleardog 4y ago
  I’m so confused about how many times it’s reiterated that _no one_ is parsing untrusted YAML with the library. It’s so unlikely as to be laughable. Then later when someone says they are, he doubles down saying that parsing arbitrary YAML provided from people on the internet isn’t parsing “untrusted” YAML because they’re authenticated. Apparently it’s reasonable that anyone that signs up for a SaaS service gets code execution privileges on the prod infrastructure? I’m pretty sure that thread had me shaking my head hard enough to give me a concussion.