Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

Re: When i am installing an Digest::SHA1 module i am getting an error like this so anyone can help on this.

by hippo (Bishop)
on May 16, 2022 at 14:40 UTC ( [id://11143920]=note: print w/replies, xml ) Need Help??


in reply to When i am installing an Digest::SHA1 module i am getting an error like this so anyone can help on this.

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.


🦛

Replies are listed 'Best First'.
Re^2: When i am installing an Digest::SHA1 module i am getting an error like this so anyone can help on this.
by afoken (Chancellor) on May 16, 2022 at 18:05 UTC
    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". ;-)

      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.


      🦛

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11143920]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others learning in the Monastery: (5)
As of 2024-03-28 14:17 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found