Re: man/mandb problem -- exploit?
On Sat, Aug 11, 2001 at 12:01:40PM -0700, Ronald Hale-Evans wrote:
> My system was recently cracked (my impression was that it happened via
> the recent Apache exploit). Shortly before I reinstalled my system
> (with better security), I lost all ability to view man pages. Typing,
> say, 'man man' would bring up a brief message about how it was
> reformatting the page, then nothing.
>
> I reinstalled, then installed an improved firewall before
> bringing the system back up on the net and doing 'apt-get update;
> apt-get dist-upgrade'. During the dist-upgrade process, I received a
> message on the root terminal saying something like 'su session opened
> for user man'.
That's normal; the installation process did that in earlier versions of
man-db (e.g. the one you have in stable). These days it uses
start-stop-daemon to avoid the syslog entry.
> I didn't know whether this was relevant, but noted it in case it had
> something to do with the man-db exploit, for which there was a fix
> released on 12 June.
So your version of man-db is now 2.3.16-4 (just checking)?
> I also ran the following commands, as recommended on the man-db
> exploit page:
>
> suidregister /usr/lib/man-db/man root root 0755
> suidregister /usr/lib/man-db/mandb root root 0755
Those instructions are wrong, as man-db 2.3.16 could not run well
without setuid privileges, while the version in testing/unstable can. I
think I pointed this out at the time - could somebody on the security
team (cc'ed) please either remove that advice in DSA-059-1 or at least
note that potato's man-db couldn't gracefully deal with being
non-setuid? (See the changelog for 2.3.18-3.)
> After the dist-upgrade, I can again no longer view man pages. As an
> ordinary user, a simple man command brings up something like the
> following:
>
> Reformatting mpage(1), please wait...
> man: can't create /var/cache/man/fsstnd/cat1/393: Permission denied
> zsoelim: /tmp/zmanp6L0Cn: No such file or directory
> man: can't unlink /var/cache/man/fsstnd/cat1/393: No such file or directory
> man: can't remove /tmp/zmanp6L0Cn: No such file or directory
I'd expect that after following the above advice. 'suidunregister
/usr/lib/man-db/man; suidunregister /usr/lib/man-db/mandb' should fix
it.
> I purged and reinstalled the packages mandb, manpages, and
> manpages-dev, with no luck. I found a file in /tmp named zmanXXXXX,
> where 'XXXXX' was a random string. When I tried to delete or view
> this file, I couldn't, because its name would change as I was trying
> to do so, to zmanYYYYY, where 'YYYYY' was another random string.
Probably while you were viewing man pages? Don't worry, those are just
temporary files created normally by man. Sometimes they used to get left
around due to bugs (maybe still do, I'll squash that bug if I see it).
> Any recommendations on getting man working on my system again are
> welcome. Be very explicit, however, as I can't use man pages to
> clarify any help that is cryptic. Moreover, does it seem that my
> man-db has been cracked?
Not to me, although I appreciate that that kind of thing is on your
mind. If you still have problems after restoring setuid permissions to
man-db, feel free to mail me privately. In that case, you can still read
man pages with something like 'zcat /usr/share/man/man1/bash.1.gz | man
-l -'.
As for your problems before you reinstalled - hard to tell, but it could
just have been a bug, or maybe whoever cracked your system changed the
permissions of some directories.
Cheers,
--
Colin Watson (Debian man-db maintainer) [cjwatson@flatline.org.uk]
Reply to: