We had some discussion to lift this check from chkrootkit (at [EMAIL PROTECTED], sorry no mail archive available), and I came to this conclusion:
A perl .packlist is always a list of absolute filenames with optional attributes (the extended syntax).
There must be only files which had been installed by perl modules.
How .packlist files could be abused:
The only point where .packlist files are read is
ExtUtils::Packlist->read(ExtUtils::Install->install_rooted_file)
These files are either removed or checked for existance or timestamp.
e.g. there's "modrm" which removes all files in the packlist or more often "make install UNINST=1".
The point is that any perl script which uses ExtUtils::Packlist or ExtUtils::Installed could be fooled to remove a system file. (The worst case scenario)
Currently there's only "modrm" (not really a danger),
and "cpan" with "o conf make_install_arg UNINST=1" or
manual "make install UNINST=1".
This might do some harm, if the attacker changed the .packlist content to remove an important file, e.g. to replace it with his trojan version somewhere down the $PATH.
A good point will be to autogenerate the md5sum for each .packlist on each installation (an easy extension to MakeMaker), but the hacker will most likely regenerate the md5sum also, if it's a MakeMaker default.
A better check will be to check
1) for a binary executable (how about par files?) along the .packlist files and
2) to check for paths not in perl %Config lib* and bin paths.
This could be added to perl's ExtUtils.
Should I come with a ExtUtils::Packlist patch for this?
See e.g. http://www.mail-archive.com/[EMAIL PROTECTED]/msg00681.html
for a Debian .packlist policy discussion.
--
Reini Urban - Entwicklung - http://inode.at
