Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • when reading a critical file (config files, modules, etc) you should always check the file permissions to be sure that nobody could possibly have modified it.

    How does that help? If an attacker has permission to change the contents of a config file then they may well have permission to chmod it back to 644 afterwards, surely?

    Further, checking the permissions with stat() and then reading the file introduces a race condition, and so does reading it first and then statting.

    Some programs like OpenSSH or Apa

    --
    -- Ed Avis ed@membled.com
    • > How does that help? If an attacker has permission to change the contents of a config file then they may well have permission to chmod it back to 644 afterwards, surely?

      No, they can't.

      (Unless the attacker has root in which case the security of your program is irrelevant anyway)


      adam@svn:~$ sudo vi tmp.pl
      adam@svn:~$ sudo chmod 666 tmp.pl
      adam@svn:~$ vi tmp.pl
      adam@svn:~$ chmod 644 tmp.pl
      chmod: changing permissions of `tmp.pl': Operation not permitted

      > Further, checking the permissions with stat() and then reading the file introduces a race condition

      No, it doesn't. (mostly)

      If the file is secure and not world-writable at the time you stat, and then you read it, the only way it could be vulnerable is if you (or you in another program, or root) changed the permissions to world-writable between the time you did the stat and when you read it.

      There may be other race conditions of course, but assuming none of the programs you might be running would delete the file and create it again fresh, and none will intentionally make the file insecure, it's reasonable to expect the file to be secure. /tmp is, of course, a whole different story.

      • No, they can't.
        (Unless the attacker has root in which case the security of your program is irrelevant anyway)

        Well, quite. To change files in /etc you need to be root, and if you are root then you can make it appear that the files have not been altered. There are conceivable cases where by some freak event a config file was set up as o+w but the directory was not writable, but I have a hard time believing it's the application's job to check for that, any more than I think applications should be constantl

        --
        -- Ed Avis ed@membled.com
        • > So why is that case any more worth checking for?

          We don't always only read files that were created at the time a program was installed?

          Plugins appear afterwards, config files get backed up and restored. Who's to say the program hasn't been upgraded since you last ran?

          There's a range of cases where this problem could appear from and not all of them would be a problem during the race window. But I agree some might, so it probably does makes sense to check both initially and then on the opened file handle.