Front page | perl.perl5.porters |
Postings from December 2012
On Dec 27, 2012, at 7:11 AM, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote: > On Wed, Dec 26, 2012 at 9:41 PM, Todd Rinaldo <toddr@cpanel.net> wrote: > >> The work around is to set $Storable::flags = 6 (in their script not >> the perl module) and it will revert the default behavior. If they >> change this globally in Storable.pm, cPanel will become insecure, so >> this is not recommended. It sounds like the people reporting these >> issues are cPanel customers. I would encourage them to open a ticket >> with cPanel if they need help. > > Would you mind elaborating on how it will become less secure? > cPanel submitted the patch we're using to the perl security list. I'm assuming it didn't make it to the public list, though I don't know since I'm about to go into p5p bankruptcy. In the Storable we are using right now, we are using a flag which drives whether variables will be blessed/tied when unfrozen. We defaulted this ($Storable::flags) to 0, which means it's off. So if someone goes into that Storable.pm file and changes it to default to 6, then taint/bless turn back on and the scripts using that Storable are now insecure. Yes it was the wrong approach. We already have reversed this in our next release. If you want to peruse the modified 2.25, you can see it here. The 2.39 patch is similar: http://httpupdate6.cpanel.net/CPAN/authors/id/cPCPAN/Storable-2.25_01.tar.gz > 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.Thread Previous | Thread Next