gebl
gebl on Hacker News
I'm not a musician, but a photographer. I think the gear craziness is probably similar across both areas. I've adapted the don't just buy gear, get out and do stuff to "Don't buy gear until you have a particular problem that gear would solve. If you can, borrow gear to validate." Because, lets be honest, sometimes the gear actually helps - but unless you have the problem it helps for its gonna sit in a corner.
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.
Its not really a problem with commons-collections and unfair to color it as their issue. Its like blaming the library that is part of a ROP chain for the exploit. The issue is what gets you in first, which is instantiating objects without any thought as to what they are from un-trusted sources.
Something that is called out in the Java secure coding guidelines:
http://www.oracle.com/technetwork/java/seccodeguide-139067.h...
and is something that goes way back in many languages. It seems to be a vuln pattern that keeps getting repeated sadly.
Right. Selling to Sun was the right thing for getting some nice hardware out there. Just saying, it gave Sun quite a competitive edge - probably bad idea from a business perspective. I was at Sun in that timeframe too, but not working on the E10ks :-)...
SGI's biggest mistake was selling Cray Research's business division to Sun. These became Sun's E10k machines and got them a tun of business outside of the desktop workstation market. It is probably what kept Sun around so long and why Oracle wanted to buy them.
http://articles.baltimoresun.com/1996-05-18/business/1996139...