|
|
|
|
|
|
by gebl
3399 days ago
|
|
|
As one of the people who did the talk at Appsec Cali that was building on all this work outlined by benmurphy... our goal was to reach security minded developers and talk about a repeated anti-pattern that put software at risk that impacts things written in many different languages. Both Chris and I have a development background, and have seen the same issue show up in ruby, python, php, basically anything that has an object serialization capability. We hoped to change the focus from a specific library or gadget to the idea that deserialization is inherently dangerous. The core problem really stems from the idea that OO models encapsulate data and behaviors. Behaviors mean code execution - so, anything that will deserialize objects is giving the person who serialized them the ability to control the execution flow. If this is a listener on the network, than things are really bad :-) So, it's great that a set of gadgets have been removed, it's neat to see the application of resources to make that happen. I have to agree with Ben, that any system that relies on object serialization from untrusted sources (in any language) is still vulnerable, it just might require a more specific gadget chain. Too many vendors have fixed their products by just updating the library and not removing the dependency on dangerous object deserailization. |
|
|