Hi, > I was playing with a static analyzer security scanner and it flagged a > time-of-check-time-of-use violation in libpq. I was going to propose a > fix for this on -hackers, since you probably can't do anything > interesting with this, but then I figured I'd better check here first. > > libpq checks the permissions of the password file before opening it and > rejects it if the permissions are more permissive than 0600. It does > this in two separate steps, first stat(), then fopen(), which is what > triggers the static analyzer. The standard fix for this kind of thing > is to open the file first and then use fstat() on the file handle for > the permission check. > > Note that libpq doesn't check who the owner of the file is or what > directory it is in. The location of the password file can be changed > from its default via libpq connection settings. So it seems to me that > if the location of the password file were a world-writable directory, an > "attacker" could supply a dummy file with 0600 permissions for the > stat() call and then swap it out for a world-readable file with > passwords for the fopen() call, both files owned by the attacker. And > so they could have the libpq application try out passwords on their > behalf. Obviously, this requires a number of unlikely circumstances, > including the ability to repeatedly exploit the gap between the stat() > and fopen() call. But it seems formally incorrect, so it seems good to > fix it, at least to make the code a better example.
Not entirely sure about the presence of a serious security issue but silencing a static analyzer sounds like a good idea, especially since the fix is simple. -- Best regards, Aleksander Alekseev
