When i am installing an Digest::SHA1 module
There's no need. Digest::SHA is in core - just use that instead.
sudo perl Makefile.PL
Stop using sudo here. It is of no benefit and increases the attack surface.
| [reply] [Watch: Dir/Any] [d/l] [select] |
sudo perl Makefile.PL
Stop using sudo here. It is of no benefit
Right.
and increases the attack surface.
How?
Makefile.PL comes from some stranger on the 'net. If you were really paranoid, that should be sufficient to simply delete it and stop installing any Perl modules. In the real world, we usually trust CPAN and run it without any checks. An attacker is limited only by your user privileges. With a sufficient amount of paranoia, you would use a dedicated, very restricted user account to build modules from CPAN, and verify all downloaded and all generated files.
Makefile.PL is expected to generate a Makefile, which is then parsed and executed by make. Still with user privileges, but it was generated by code you should not trust. Do you read it line by line or do you just run make? Again, an attacker is limited only by your user privileges. Hiding malicious behaviour in the generated Makefile instead of Makefile.PL might be creative, but has no advantage (i.e. increased attack surface).
Next step: Run the tests: make test. Essentially, nothing has changed.
Now what? You install your new module. Globally, for all users. Using sudo to gain root privileges: sudo make install. And at this point, you hand out the keys to your computer. Hiding malicious behaviour in the generated Makefile gains root privileges, with a default installation of sudo, this is typically unrestricted.
So, even with the default perl Makefile.PL && make && make test && sudo make install, any CPAN distribution may take over your computer.
Assuming I wanted to implement an attack, why should I bother checking if Makefile.PL was invoked accidentally with root privileges, if a few steps down the installation process I am guaranteed to get root privileges during installation? And of course, a working perl and probably also a working C compiler?
Code in Makefile.PL will ultimatively be executed with root privileges. Maybe not by perl, but by make or the shell. So I don't see how the attack surface could be larger than running code from the network.
Heck, if you want to run perl code as root, just invoke Makefile.PL from the Makefile and have it check for root privileges to switch between preparing the attack and attacking:
/tmp>cat Makefile.PL
#!/usr/bin/perl
use strict;
use warnings;
use autodie;
if ($> == 0) {
print "Say goodbye to it all ...\n";
exec "echo","rm","-rf","/";
}
open my $out,'>','Makefile';
print $out <<'__magic__';
default:
@echo All done
test:
@echo No tests
install:
perl Makefile.PL
__magic__
close $out;
/tmp>perl Makefile.PL
/tmp>make
All done
/tmp>make test
No tests
/tmp>sudo make install
Password:
perl Makefile.PL
Say goodbye to it all ...
rm -rf /
/tmp>
Yes, I'm completely ignoring any non-Unix system and per-user installations of perl. How much damage can a malicious Makefile.PL do without root privileges? rm -rf / invoked as non-root user will still ruin your day, but with more error messages.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply] [Watch: Dir/Any] [d/l] [select] |
Those are all good points (++).
Nevertheless, I remain of the opinion that using sudo only when actually required does help to minimise the possibility of problems arising. Such problems may be caused by malice but also by incompetence either on the part of the distributor or on the part of the user (such as running the command in the wrong directory/window/VM/whatever or just with a typo). It is (IMHO) a good habit to acquire.
Additionally, a properly paranoid user won't use elevated privileges at any point in the installation process. Instead they will choose to install into a directory where their unprivileged user has the required write access (eg. with local::lib, perlbrew, etc.). That's probably as much mitigation as the average user will ever need or accept. It's always a trade-off between security and convenience after all.
| [reply] [Watch: Dir/Any] [d/l] |
| [reply] [Watch: Dir/Any] |