1. 24
  1.  

  2. 3

    I actually worked at a hosting company and received some of the reports in this story, so it is pretty neat to see this post with the results.

    1. 2

      What’s the approach to disclosure when a website is notified about a breach like this? All bets are off as to what information has been leaked, so I suppose you wouldn’t be able to guarantee that your users’ data hasn’t been compromised.

      1. 2

        Depending on the age of the file you might be able to just check logs for 200 responses to GET /core.

        1. 2

          This is a challenge you always have after you learned about a severe security vulnerability. What have you done after heartbleed? Or any other bug that has the potential to leak information?

          To be honest: In this case I’d say just fix it and move on. If you have logs you can check whether someone else has tried to access that file. (To the best of my knowledge this issue wasn’t discussed publicly before my blogpost and article today. However I don’t know if others knew it and used it for attacks.)

        2. 1

          I wonder how many shared PHP hosts are vulnerable to information leaking via:

          1. writing a blob of php that does something dumb to segfault the process
          2. running it on a machine on which the php processes are shared between multiple users 3 downloading copies of the resulting core files, if they’re written somewhere that is visible to you (perhaps you could chdir() somewhere you have read and write access first?)
          3. searching the core files for information in the (remnants of the) heap belonging to unrelated programs that were executed by the same interpreter