> Von: Ondřej Surý [mailto:ond...@sury.org] > > Control: tags -1 +pending > > On Tue, Oct 21, 2014, at 11:33, Ondřej Surý wrote: > > On Tue, Oct 21, 2014, at 11:16, Fiedler Roman wrote: > > > > Von: Ondřej Surý [mailto:ond...@sury.org] > > > > > > > > On Tue, Oct 21, 2014, at 10:55, Fiedler Roman wrote: > > > > > > Von: Ondřej Surý [mailto:ond...@sury.org] > > > > > > > > > > > > Hi, > > > > > > > > > > > > TL;DR: "s/touch -c/touch -c -h/", right? > > > > > > > > > > This will fix it for arbitrary symlinks, the only remaining issues > > > > > would > > > > > be > > > > > > > > > > a) keeping open a file ".. xxxx", which will update the parent > > > > > directory > > > > > modification time. > > > > > > > > Which parent directory? The session dir or the symlink targe parent > > > > directory? > > > > > > The /var/lib directory: Since the the parsing of the lsof output is > > > broken (awk uses "$9"), an open file ".. xxxx" will cause touch -c > > > "/var/lib/php5/.." without involving any symlinks. > > > > I see... > > Thanks for the analysis, while the impact is very low, it's worth > updating. > > > [ -x /usr/bin/lsof ] && /usr/bin/lsof -w -l +d "${1}" -Fn | grep -E "^n" > > | cut -b 2- | xargs -i touch -c -h {} > > This change will be included in next wheezy update of PHP.
No, this seems not to solve it (I hope I haven't screwed something up while testing), consider the sequence (PID ordering is important!): mkdir -p $'/var/lib/php5/xxx\n/var/lib' ln -s /etc $'/var/lib/php5/xxx\n/var/lib/php5' sleep 1000 > '/var/lib/php5/xxx\' & sleep 1000 > /var/lib/php5/passwd & Even touch -h does not help here, only kernel symlink protection prevents damage. But maybe this is a problem with xargs usage? If it is an xargs-bug this would have a much broader scope, more another topic for security@d. > > JFTR jessie&sid has a new script that takes a different approach and > > might suffer from the same bug if you manage to open a file in > > /var/lib/php5/sessions/ with active php5 process. > > If you find a similar vulnerability in the new session script, please > open a new bug. Looking at the new script, I guess that it should be possible for any user allowed to write to sessions to update any file he has read access to it. But of course, it is not so simple as with old script. To proof this, I would have to prepare a machine with sid (unless you have one ready with remote SSH for testing)
smime.p7s
Description: S/MIME cryptographic signature
