Re: File handling races in bzip2, bzip2recover
> 1) The file is opened after the test, in such a way that if a file is
> placed there between the test and the fopen, the file is silently
> overwritten. Or a symlink could be placed there by a malicious user
> and then bzip2 would overwrite the file pointed at.
So what? Are we going to audit every binary in the distribution for race
conditions? bzip isn't setuid and doesn't run with elevated permissions
by default. It would be nice to fix this, but I do not think it's
release critical.
> 2) (minor) The output file is initially opened with weak permissions,
> then chmod'ed. Again a race, where an attacker could access the file
> between creation and chmod.
I'm ambivalent about this one. On one hand, the user might not be aware
that the permissions on the final output were not preserved throughout
the process. On the other hand, the user's umask should be set
appropriately so that this doesn't matter.
In short, I think this is yet another case of bug severity inflation.
Please, people, remember that some bugs are not release critical.
--
Mike Stone
Reply to: