in reply to Patch an old Perl version

  1. Is this old version of perl running publicly accessible applications?
  2. Are those applications building hashes from third-party derived data?
  3. Are those applications of sufficient import that anyone would attempt to compromise them?
  4. Do the applications in question build sufficiently large hashes, such that if they used 20 buckets of 128, instead of 38 buckets of 64, in order to store 56 keys; that when scaled up to their typical capacities, they might run out of memory?
  5. Do these applications represent sufficiently rewarding -- either financially, commercially, or politically -- targets that there might be potential assailants prepared to expend the substantial time, resources and money -- not to mention risking their personal freedom if caught -- to pursue attempting an exploit that:
    • has never been proven to be feasible;
    • can be shown to require sustained and concentrated (and easily detectable) probing over long periods of real time to effect;
    • can be reasoned to be almost impossible to carry out;

In the unlikely event that you can say yes to all of those, then you'd absolutely be better to upgrade to a newer perl than to attempt to patch; given that in the interim there have been countless other bug fixes and improvements to the Perl sources; many of which leave your old version of Perl far more vulnerable than this speculative and theoretical exploit.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^2: Patch an old Perl version
by Discipulus (Canon) on Nov 08, 2013 at 12:13 UTC
    ok seems you right. I'll plan a Perl's version upgrade to a 5.18

    Thanks
    L*
    There are no rules, there are no thumbs..
    Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.
[reply]
[d/l]
Re^2: Patch an old Perl version
by demerphq (Chancellor) on Nov 10, 2013 at 11:38 UTC

    While I generally agree with your gist here I feel compelled to point out that with regard to CVE-2013-1667 point 4 is plain wrong, and that 5, while attempting to make a valid point contains inaccuracies and appears to be based on the mistaken understanding that CVE-2013-1667 is a normal hash collision attack.

    Point 4 is plain wrong because a successful attack requires much less keys than you realize. I feel obliged to be coy about how many but rest assured the number is small enough to be a real threat.

    Point 5 contains a valid point that this attack is probably of concern only to business scale installations. However the rest of the points it makes are at best applicable to a standard hash collision attack but do not apply to the REHASH attack at all. Specifically, the REHASH attack is *proven*, (or there would be no one-line test for it), requires no probing, and far from being "almost impossible" is actually trivial execute. To attack various web platforms one would simply construct an URL containing the right keys as parameters to the request, and since the proof of concept attack requires only chars in "a-z" doing this is trivial.

    Anyway, with regard to true hash collision attack I generally agree with your line of thinking in this post, and indeed my paper on it said more or less the same thing. But the REHASH attack is in a different category, and should not be confused with a classical hash collision attack.

    ---
    $world=~s/war/peace/g

[reply]
      Specifically, the REHASH attack is *proven*, (or there would be no one-line test for it)

      Sorry n'all, but that is rubbish.

      *All* your one liner demonstrates is: does this perl contain that change/patch? Nothing -- literally nothing -- more.

      It in no way makes any attempt to demonstrate why the patch might be needed.

      It simple demonstrates that something is different; without giving any indication of how -- or even whether -- the changed behaviour is an improvement in some way.

      , requires no probing, and far from being "almost impossible" is actually trivial execute.

      Again. A bland statement unsubstantiated by your post; your paper; the text of CVE-2013-1667; or anything else that you've have said publicly on the subject(*).

      To attack various web platforms one would simply construct an URL containing the right keys as parameters to the request, and since the proof of concept attack requires only chars in "a-z" doing this is trivial.

      Again. This is so trivialised a scenario as to be meaningless.

      A whole bunch of reasoning deleted; let's cut to the chase ...

      So, if I send you a url of a perl script running on my machine under an unpatched version of Perl; you'll make it crash in short order?

      *that I've been able to find. After months of looking!

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

        Sorry, but I do not believe it is responsible to reveal the attack key set at this time. Everybody on the perl5-security list has seen the full attack set and can confirm what I say about it. The fact they rolled security releases for all the major versions should be sufficient proof.

        ---
        $world=~s/war/peace/g

[reply]
        The attack is real and proven. I've let it crash my machine in a realistic simulation of the real world. Please patch your world-facing perls.
        rjbs
[reply]

In Section Seekers of Perl Wisdom