Re: NSS
The problem is that serialisation is awfully convenient.
A well known MMOG - written in a non-Java language I won't mention because it would probably give the game away - uses serialisation for network communication. Many years ago I dug into it that part of it and quickly found a dozen separate vulnerabilities (some of them caused heap corruption, some just causing memory violations that would bring down the targetted client or server without taking it over, etc).
The most egregious involved them allowing a limited set of method calls to be serialised. A sort of a la carte direct-'gadget' menu. My creative juices began flowing dreaming up the most majestic exploit that could be written with such tools. Of all the possibilities for combining them which would I choose? But the inventive process was cut short when one of the methods turned out to be "Hey, run this arbitrarily long string of code for me please".
The more difficult problem was how to get across to the company the breadth of the problem. You could see why they'd done it, apart from the gaping security issue, the architecture was powerful but clean. You could abstract really complex object behaviour, throw the object across a TCP connection or some shared memory to another process, put it in a database, and retrieve it years later when your codebase had moved on, all without caring much what the object was in the first place. Knowing the genesis of the game, how rapidly it was prototyped with so few developers, it's quite likely it wouldn't have come to market without some form of serialisation of untrusted input. And the world would be a poorer place for that *shrug*
Biting the hand that feeds IT
