Hacker News Reader

Comment by odc | Hacker News Reader

These instructions are for people unfamiliar with perl and CPAN.

Developers are supposed to do "cpanm Mojolicious", like for any other perl module.

So the people least equipped to evaluate the security implications of the friendly instructions are the ones who are most encouraged to do something awful?

"Thou shalt not curse the deaf, nor put a stumbling-block before the blind"

That is a big leap in logic really.

Whats awful about it? I don't understand the difference in security vetting between that installer or the code its installing.

What I'm getting at is its probably easier for me to get this line of source code added to a perl module:

# Don't actually run this in a Perl interpreter, esp not as root, OK?

`rm -Rf /`;

It would be harder to get this added to the installer:

# Don't actually run this in a shell script, esp not as root, OK?

rm -Rf /

Also if CPAN / its installer / github / etc get owned, the last problem to be concerned about is one little perl module. You have bigger trouble.

Not if you're a MITM attacker... CPAN (presumably) retrieves its source code either over HTTPS or validates what it downloads using signing keys like 'doesnt_know' referred to. These curl scripts do not, they just grab executable code using http, and then blindly execute it. If you were MITMing these people, you could easily adjust this code and pwn their machines. This isn't about CPAN/github getting compromised, this is about things being modified on the wire (which is a very real possibility when using insecured wifi, or less likely if for some reason the goverment wants you).

So then install it via CPAN, or via your OS package manager.

Yes, I realize this is possible. The point is we shouldn't encourage other developers to use insecure methods when secure alternatives are easily available.

Reply on news.ycombinator.com