"The prosecutors recognized that there was no evidence against Mr. Swartz indicating that he committed his acts for personal financial gain, and they recognized that his conduct - while a violation of the law - did not warrant the severe punishments authorized by Congress and called for by the Sentencing Guidelines in appropriate cases."
Does ruby's Marshal have the same problems that python's pickle have? Could you construct a valid Marshal bitsting that when loaded would run malicious code? Is this exposing folks to a MITM attack on rubygems?
I don't know what the specific issue with pickle is, but ruby's Marshal format is pretty bulletproof at this point. It is a data only format with pretty strict verification of the stream as it builds the object tree.
Also, Marshal doesn't allow any kind of code to be included into the stream, so there is no ability for stream to perform remote code injection.
Marshal call back into Ruby for non-builtin types, but it does so by simply calling a method on the constant and passing either the raw Marshal data or a previous created object tree. This provides enough protection that there haven't been any reported cases of it being exploited and no know issues exist with it.
I'd be willing to stake some money on a bet that they're going to regret the decision to build key Ruby infrastructure on Marshal, say, within 12 months.
Having said that, I cannot at this moment tell you how to take over a Ruby runtime with a malicious Marshal byte string.
What about the old Marshal problems? I just played with Marshal on my rails console again and it seems it still encapsulates all sorts of implementation details. I haven't tried whether it's now compatible across Ruby versions, but I recall the Marshal format changed a few times, introducing incompatibility.
Not sure what you mean by Marshal having implementation details in the bitstream, it doesn't. Marshal has been reimplemented in many different implementations just fine.
As for why not JSON, because there is no JSON parser as part of the standard library and rubygems needs to be extremely careful about what dependencies it has.
AFAIK, Ruby's Marshal only calls internal stuff like allocate and special Marshal methods (e.g. marshal_dump and marshal_load) on classes in the Marshal data. It doesn't even actually use new or initialize to create instances, and it doesn't go through methods to set up the object. So unless you have a class that overrides Marshal hooks or Ruby internals in an insecure way, it shouldn't allow arbitrary code execution (barring buffer overflows and the like that could allow arbitrary code execution from any function).
Basically, I'm not convinced Marshal is necessarily any more risky than something like YAML would be, even though it feels scarier. But I haven't done an extensive audit or anything — I just looked over the Marshal code a while back because I was curious what it was doing.
Keep in mind that the problems we're having aren't with XMPP, per se, just with ejabberd. Ejabberd worked flawlessly for several months until it started exhibiting some very strange behavior and performance characteristics. We upgraded to a newer version and we suddenly ran into another, different set of strange behaviors.
That said, word on the street is that ejabberd is the best implementation of an XMPP server. AMQP supposedly offers better reliability (with RabbitMQ) as well as a whole lot of pretty cool features that Jabber really doesn't.
Huge processor spikes which we think are caused by too many connections to a single room or user. We're not 100% sure because we can't replicate it in a dev environment and we don't really want to turn on debugging in a production environment, not to mention that debugging mode isn't the most helpful thing ever.
If you start it up in "live" mode (ejabberdclt live), we see "Replacing connection..." sometimes, which then throws a "Broken Pipe" error in our rails app. But again, we can't isolate what's happening there.
No. You don't get it. Try again.