In article <20010604130304.A4657@gringgo>, "Luki R ." <lukiat_private> wrote: >In some conditions, man allow user's PATH env. to be inserted as manpath. >Man then use manpath value for searching directories contain manpages. >This is ok until man forgot to drop privilledges when creating cat pages >cache files using user's supplied PATH. > >I've successfully try this on 2 different man system, debian's and redhat's. >Yes, this is not a new bugs since debian hax fixed it on man-db 2.3.18-6 >in unstable (hi Colin Watson :)) and 2.3.16-4. Heh, thanks. I should note that it had already been fixed in 2.3.18 (i.e. 2.3.18-1 - so really everything up to 2.3.16-3 in stable and 2.3.17.1-5 in testing/unstable is vulnerable), as I decided that that particular change was a good idea on general principles. I didn't know that it was exploitable until you filed your bug, so I hadn't updated the stable release. However, as far as I know this will be fixed in Debian 2.2r4, and in the meantime you can get 2.3.16-4 from proposed-updates. Easy lesson from this bug, and one I doubt is unique to man: if you have functions to drop and regain effective privileges in a set[ug]id program, make sure they nest properly. In this case, man did some things "with dropped privileges" while privileges were already dropped, and thus regained them too early in a few cases. >- suid / sgid man binaries [1] & [2] (to be able to write to cache dirs) FYI, as of Debian man-db 2.3.18-3, man and mandb are shipped unprivileged (the user is asked if (s)he wants them setuid, but the default is no). Cat pages and database updates are nice and all that, but patching security holes was getting very old very quickly. Thanks for your report, -- Colin Watson [cjwatsonat_private]
This archive was generated by hypermail 2b30 : Mon Jun 04 2001 - 22:42:35 PDT