Sign in / up

back to article Quick PHP patch beats slow research reveal

Patches have been flung out to cover vulnerabilities in PHP that led to remote code execution and buffer overflows. The flaws were detailed this week by Swiss researchers High-Tech Bridge in versions 5.4.33, 5.5.17 and 5.6.1 on a machine running Ubuntu 14.04.1 LTS and the Radamsa fuzzer. A patch issued last month for CVE-2014 …

COMMENTS

Post your comment
House rules Send corrections
Add to 'My topics' unstar *
  1. Anonymous Coward
    Anonymous Coward

    Does the P in LAMP means "Patch" - and Patch often? PHP itself loosk more an acronym for Patch, Hell, Patch!

    5 17 Reply
    1. Anonymous Coward
      Reply Icon
      Anonymous Coward

      Maybe you should read http://php.net/ChangeLog-5.php sometimes...

      0 0 Reply
    2. bigtimehustler
      Reply Icon

      Haha, yea, so everyone should be using java instead? Oh wait....

      2 0 Reply
      1. elip
        Reply Icon

        like a presidential election...

        ...that's a false dichotomy. I *think* you implied both are horribly insecure pieces of software that surprisingly power a good chunk (most?) of the world's web apps. I agree...security record of both java and php are abysmal.

        2 0 Reply
      2. Anonymous Coward
        Reply Icon
        Anonymous Coward

        "Haha, yea, so everyone should be using java instead? Oh wait...."

        As a more realistic option, .Net / IIS / SQL has a much much better security record in recent years than both LAMP and Java based stacks. Better support too.

        1 2 Reply
    3. Skymonrie
      Reply Icon
      FAIL

      If you rely on a single piece of software, the same piece of software that "delivers" to secure your entire stack, you're doing it wrong regardless of whether you call it PHP, IIS, Java, Ruby, Node, etc.

      0 2 Reply
      1. Skymonrie
        Reply Icon

        To the downvoters, when I talk about having no single point of failure within software, I mean having a resilient environment.

        Specifically addressing the bug in question, with proper input validation/sanitation data that could cause this bug would never get in to the system to begin with. How often do people store integers larger than 9223372036854775807 (for use in a PHP environment), especially from a serialized source?

        On a typical website, if receiving "extreme" data (valid data but unexpected) I'd write details to a log and/or ask the user if they are sure they mean to use such a large value.

        Either way, kudos to the PHP team for addressing the issue so quickly

        0 0 Reply

POST COMMENT House rules

Not a member of The Register? Create a new account here.

Forgotten password ?

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like