Front page | perl.perl5.porters |
Postings from December 2012
On Thu, Dec 27, 2012 at 5:26 PM, Todd Rinaldo <toddr@cpanel.net> wrote: >> If cPanel is deserializing untusted Storable data and hoping to make >> it secure by not allowing objects (and thus disallowing code loaded at >> a distance or executed at a distance via DESTROY) that's probably only >> a cosmetic improvement. > > I wasn't directly involved in the original research. I see your point, which I take to be: Tainted data is tainted. It was looked into when we did this research and we're happy with the security short of the bless/taint issues. As I understand it, other companies are streaming data between untrusted sources too, just with a different module. Do you consider for instance JSON streaming to be insecure? > >> I don't think Storable is meant to handle arbitrary untrusted input. > How do you see Storable as any less safe than say JSON if Tie/Bless/CodeRefs are turned off? > > To be clear, cPanel did not hold back the patch. We were told it needed more consideration than time allowed with respect to our security release. > > I'm all for seeing the patch go into a future version of Storable. As to whether it should default to secure and break legacy, I would love to see it do so in blead and then we could go fix CPAN to not break on this. I would think this would be a good opportunity to Validate that these modules are safely using Storable. If their need to thaw blessed/tie/coderefs is valid, then they can just do a "local $Storable::flags" and/or pass a second arg to the thaw routines to be explicit that they want that behavior. Though to be honest, I'd prefer seeing load and bless as separate operations. In most examples I've seen of Storable's use, usually only the outer hash is blessed. > > There are lots of assumptions in the above paragraph. I'd love to see them discussed. Modules that handle JSON were written & designed to handle untrusted data, Storable is not. See https://github.com/mirrors/perl/commit/664f237#L1R1022 for a recent note Steffen added to the documentation about this. You're mitigating some of the issue by turning off the deserialization of objects, but you're still using a module that mostly deserializes perl's internal datastructures as-is into your current interpreter. That has a much larger attack surface than something like a JSON module. I'm curious as to why you're using Storable at all if you don't support the deserialization of objects, to preserve things like UTF-8 flags and binary data?Thread Previous | Thread Next