5 ms·

Any sufficiently advanced serialization standard will let you serialize/deserialize a wide variety of objects. When J2EE SOAP libraries are passing large amoun

by 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.).
  - pifflesnort 14y ago
    > 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? No. You're conflating code and state (which was the problem to begin with!) Let's disassemble parsing a list of strings: When you instantiate the individual string objects, you do not 'eval' the data to allow it to direct which string class should be instantiated. You also do not 'eval' the data to determine which fields to set on the string class. You instantiate a known String type, and you feed it the string representation as an array of non-executable bytes using a method you specified when writing your code -- NOT a method the data specifies. The data is not executable. It's an array of untrusted bytes. The string code is executable, and it operates on state: the data. You repeat this process, feeding the string objects into the list object. At no point do you ask the data what class or code you should run to represent it. Your parsing code dictates what classes to instantiate, and the data is interpreted according to those fixed rules, and your data is never executed. It should never be possible for data to direct the instantiation of types. The relationship must always occur in the opposite direction, whereby known types dictate how to interpret data. > I think it was not obvious to a bunch of people who are in retrospect _claiming_ it was obvious to. Given the preponderance of prior art, this seems unlikely.
rst 14y ago
Spring isn't the only widely-used Java framework that's had these problems. The Struts developers put a general-purpose interpreter (OGNL) in their parameter parsing pipeline, and thought they'd kept things safe by blacklisting dangerous syntax. Wackiness ensued: http://blog.o0o.nu/2010/07/cve-2010-1870-struts2xwork-remote.html http://blog.o0o.nu/2010/07/cve-2010-1870-struts2xwork-remote... It would obviously be unfair to claim on this basis, or the recent problems with the Java browser plugin, that the "entire Java language community" has a bad attitude on security matters. Communities are big, each of them has a range of attitudes within it, and most importantly --- regardless of attitude --- sooner or later, everyone screws up.
yuhong 14y ago
Another example is ATL: http://technet.microsoft.com/en-us/security/advisory/973882 http://technet.microsoft.com/en-us/security/advisory/973882
joseph_cooney 14y ago
I guess the difference re: spring is that I don't load my spring configuration via a HTTP connection that is pointed to the internet.
zzzeek 14y ago
Parsing is not deserialization. I keep having to say this on all these threads. There should be a giant glowing force field between these two practices. the particular issue in the Yaml parser is explained pretty well here: http://www.insinuator.net/2013/01/rails-yaml/ http://www.insinuator.net/2013/01/rails-yaml/
makomk 14y ago
The security fuckup is a lot more simple than that - they fucked up as soon as they opened the door to this kind of complicated interaction by letting untrusted code instantiate arbitrary classes and pass strings of their choice to them. Doesn't matter that they weren't aware of any way this could be exploited, as soon as they let an attacker pass data to random classes that were never designed to accept untrusted input a security disaster was basically inevitable.

by patio11 14y ago

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.).
- pifflesnort 14y ago
  > 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? No. You're conflating code and state (which was the problem to begin with!) Let's disassemble parsing a list of strings: When you instantiate the individual string objects, you do not 'eval' the data to allow it to direct which string class should be instantiated. You also do not 'eval' the data to determine which fields to set on the string class. You instantiate a known String type, and you feed it the string representation as an array of non-executable bytes using a method you specified when writing your code -- NOT a method the data specifies. The data is not executable. It's an array of untrusted bytes. The string code is executable, and it operates on state: the data. You repeat this process, feeding the string objects into the list object. At no point do you ask the data what class or code you should run to represent it. Your parsing code dictates what classes to instantiate, and the data is interpreted according to those fixed rules, and your data is never executed. It should never be possible for data to direct the instantiation of types. The relationship must always occur in the opposite direction, whereby known types dictate how to interpret data. > I think it was not obvious to a bunch of people who are in retrospect _claiming_ it was obvious to. Given the preponderance of prior art, this seems unlikely.

rst 14y ago

Spring isn't the only widely-used Java framework that's had these problems. The Struts developers put a general-purpose interpreter (OGNL) in their parameter parsing pipeline, and thought they'd kept things safe by blacklisting dangerous syntax. Wackiness ensued: http://blog.o0o.nu/2010/07/cve-2010-1870-struts2xwork-remote.html http://blog.o0o.nu/2010/07/cve-2010-1870-struts2xwork-remote... It would obviously be unfair to claim on this basis, or the recent problems with the Java browser plugin, that the "entire Java language community" has a bad attitude on security matters. Communities are big, each of them has a range of attitudes within it, and most importantly --- regardless of attitude --- sooner or later, everyone screws up.

yuhong 14y ago

Another example is ATL: http://technet.microsoft.com/en-us/security/advisory/973882 http://technet.microsoft.com/en-us/security/advisory/973882

joseph_cooney 14y ago

I guess the difference re: spring is that I don't load my spring configuration via a HTTP connection that is pointed to the internet.

zzzeek 14y ago

Parsing is not deserialization. I keep having to say this on all these threads. There should be a giant glowing force field between these two practices. the particular issue in the Yaml parser is explained pretty well here: http://www.insinuator.net/2013/01/rails-yaml/ http://www.insinuator.net/2013/01/rails-yaml/

makomk 14y ago

The security fuckup is a lot more simple than that - they fucked up as soon as they opened the door to this kind of complicated interaction by letting untrusted code instantiate arbitrary classes and pass strings of their choice to them. Doesn't matter that they weren't aware of any way this could be exploited, as soon as they let an attacker pass data to random classes that were never designed to accept untrusted input a security disaster was basically inevitable.