[pkg-fetchmail-maint] Bug#452907: Bug#452907: .fetchmailrc not permitted to be a symlink

[Roger Leigh]

Nico Golde <nion at debian.org> writes:

> Hi Roger,
> * Roger Leigh <rleigh at whinlatter.ukfsn.org> [2007-11-26 23:21]:
>> Nico Golde <nion at debian.org> writes:
> [...] 
>> > But this could introduce some race condition with permission or uid
>> > checks. This behaviour also prevents symlink attacks :)
>> 
>> I'm not sure I see why, given that this is a config file--we aren't
>> writing to it, which would be a case for a symlink attack.
>
> I did not check it, was just a thought. Don't know if for 
> example fetchmail when run as root will print out errors 
> that can be used to get sensitive information if the 
> fetchmailrc is linked for example to shadow. However, no 
> idea I did not check it.



>> > So we suggest to workaround this by either adding a hardlink (if this works with git internals)
>> > or executing -f - <"${HOME}/.fetchmailrc".
>> 
>> Hardlinking won't work.
>
> Why not?

git unlinks the file when it gets replaced by a newer version,
breaking the association.  This is not the case for a symlink.

>> The latter is a good idea--I'll try that in the meantime.
>
> Any results? Upstream regrets to implement this until you 
> raise your hand with a very good reason while I agree with 
> you because I also dont see a reason to not do this :)

This does work, thanks.


My main problem with the current behaviour is not that it isn't
secure--I've checked the code and its use of lstat() is reasonable
(albeit no xattr checking).  Note that there is still a race here
between the lstat() and fopen(), so the config file could be replaced
or altered between the check and before the fopen().  To do security
properly, races should be eliminated.

The checks limit the flexibility of how the user can use the program.
If fetchmail were just to open() and fstat(), the symlink is never
checked (which is less secure) but the file actually being pointed to
is, and that's the important one, and it's also race free.  Of course,
a malicious hacker could replace the user's .fetchmailrc symlink to
make it point to an alternative file owned by the same user, but
really, the user has more serious problems at this point--if their
.fetchmailrc link can be altered, so can the file it points to.

IMO, the best option would be to fstat(fileno(yyin)) in
prc_parse_file().


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-fetchmail-maint/attachments/20071128/988a4c38/attachment.pgp