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:
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.
This is absolutely true. SGI was trying to decide between shutting down Cray BSD entirely or shunting it off to Sun -- who was really the only possible buyer (their product was based on SPARC and Solaris, even when at Cray). So SGI wasn't going to make a nickel off of that product, and as such, it remains one of the best acquisitions in the history of the industry: purchased for less than $10M (I'm not sure the exact figure was ever disclosed), that product line did $1.2B in top line in its first year at Sun -- and it's hard not to have fond memories of that year. (Speaking personally, debugging a nasty performance problem on an E10K in December of 1997 helped to directly inspire DTrace[1]; I will always remember that machine fondly, despite its many quirks.)
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 :-)...
