Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

Patch an old Perl version

by Discipulus (Canon)
on Nov 08, 2013 at 08:58 UTC ( [id://1061679]=perlquestion: print w/replies, xml ) Need Help??

Discipulus has asked for the wisdom of the Perl Monks concerning the following question:

hello there.
I read here that older Perl distros are affected by an hash function vulnerability.
I have to admit that i understood only one third of the explanation.. but fortunately there is a simple oneliner to test your version, and one of mines prints "not ok".

>perl -le"@h{qw(a h k r ad ao as ax ay bs ck cm cz ej fz hm ia ih is i +z jk kx lg lv lw nj oj pr ql rk sk td tz vy yc yw zj zu aad acp acq a +dm ajy alu apb apx asa asm atf axi ayl bbq bcs bdp bhs bml)}=(); prin +t %h=~/128/ && qq(not ),qq(ok # perl $])" not ok # perl 5.008008 >perl -v This is perl, v5.8.8 built for MSWin32-x86-multi-thread (with 25 registered patches, see perl -V for more detail)
Where can I find a patch for my distro? How can apply it? I need to recompile from source? or better replace with a 5.18 when it is possible.

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.

Replies are listed 'Best First'.
Re: Patch an old Perl version
by BrowserUk (Patriarch) on Nov 08, 2013 at 09:29 UTC
    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.
      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.

      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

        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.
Re: Patch an old Perl version
by Corion (Patriarch) on Nov 08, 2013 at 09:09 UTC

    If this is the Perl as distributed by your vendor, you should look at whether your vendor supplied a patched version already as a package.

    If your OS is out of vendor support, you should compile your own Perl, at least for all services that are reachable from the outside (web).

    Update: I only now notice, after posting, that you are using ActiveState or Strawberry Perl. I'm not sure if ActiveState supports 5.8.x, but I'm quite sure that Strawberry doesn't. So your best approach is to move the 5.8.x Perl away to a safe location and replace it with a newer version.

Re: Patch an old Perl version
by sundialsvc4 (Abbot) on Nov 08, 2013 at 21:59 UTC

    Hmm....   This brings up a couple of side-questions to me:

    1. Where does Perl.org (or any other related group ... CPANTS?   CERN?) ... discuss security-vulnerability issues and which versions of Perl are or are not affected by them?   If I wanted to read more about this particular issue, say, where would I go?   (Let’s say that I am not interested in distributor-specific updates/packages, but the interpreter in general.)
    2. Does Perl use the “patch” mechanism to make minor-version updates (e.g. “5.08.yy”) to the core system?

    I know this must be well-documented somewhere ... but ... where, exactly?

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://1061679]
Approved by BrowserUk
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others wandering the Monastery: (5)
As of 2024-03-19 10:35 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found