diff --git a/docs/blog/2022-09-21-reining-in-unruely-aliens.blog_item.md b/docs/blog/2022-09-21-reining-in-unruely-aliens.blog_item.md new file mode 100644 index 0000000..43a0103 --- /dev/null +++ b/docs/blog/2022-09-21-reining-in-unruely-aliens.blog_item.md @@ -0,0 +1,51 @@ +## Reining In Unruely Aliens + +By Graham Ollis on 21 September 2022 + +When I have talked to Perl developers about the Alien technique, some are +rightly concerned about the security implications of downloading arbitrary +stuff off the internet. My response to this has always to point out that +if you are installing modules from CPAN then you are doing the same. + +In fact the default for one of the most popular cpan clients is to use an +unencrypted http connection to fetch modules off the internet. The default +for the Perl's in core HTTP client is to not verify server identity making +man in the middle attackes much easier. There are historical reasons for +these decisions, but overall I think these are examples of how Perl is +increasingly out of step with the rest of the internet. + +The team responsible for M and M +plan on making it easier for users to control the security model for +downloading and installing alienized packages for Ms that use them. +We also plan on changing the default model to err on the side of more +secure. None of these changes is a substitue for properly auditing +the open source code that you use, if your threat model dictates that. +At the end of the day, although there are a few Perl modules that can +be installed statically, the vast majoirty still rely on executing a +`Makefile.PL` or `Build.PL` which is arbitrary Perl code. + +The TL;DR is that if you are an Alien author, or if you are the author +of an M you should check to +see if your modules still work when `ALIEN_DOWNLOAD_RULE` is set to +`digest_or_encrypt`, which will soon become the new default. This +will require that alienized packages be either + +* Downloaded using a secure protocol such as `https` +* Checked with a cryptographic signature included in the M (or `Build.PL` for M based aliens) +* Bundled within the M itself. + +For more details on the security implications please see +M. + +I have already gone through all of the plugins that I am aware of and +fixed them. (Unfortunately even plugins that do not modify the +fetch or download stages of L are potentially susceptible +because their tests often need to fake the fetch and download steps +and may do so in a way that seems unsafe to L). I will +also go through all of the aliens that I have control over to make sure +they work with this new default. + +None of this completely removes the peril of downloading arbitrary +software off the internet, but it does improve the default security +model, and gives the end user more control over the security model +via the `ALIEN_DOWNLOAD_RULE` environment variable. diff --git a/docs/blog/2022-09-21-reining-in-unruely-aliens.html b/docs/blog/2022-09-21-reining-in-unruely-aliens.html new file mode 100644 index 0000000..b4e7461 --- /dev/null +++ b/docs/blog/2022-09-21-reining-in-unruely-aliens.html @@ -0,0 +1,81 @@ + + + + + Reining In Unruely Aliens + + + + + + +
+
+
🌻 🪵 Reining In Unruely Aliens
+

By Graham Ollis on 21 September 2022

+ +

When I have talked to Perl developers about the Alien technique, some are +rightly concerned about the security implications of downloading arbitrary +stuff off the internet. My response to this has always to point out that +if you are installing modules from CPAN then you are doing the same.

+ +

In fact the default for one of the most popular cpan clients is to use an +unencrypted http connection to fetch modules off the internet. The default +for the Perl's in core HTTP client is to not verify server identity making +man in the middle attackes much easier. There are historical reasons for +these decisions, but overall I think these are examples of how Perl is +increasingly out of step with the rest of the internet.

+ +

The team responsible for Alien::Build and Alien::Base::ModuleBuild +plan on making it easier for users to control the security model for +downloading and installing alienized packages for Aliens that use them. +We also plan on changing the default model to err on the side of more +secure. None of these changes is a substitue for properly auditing +the open source code that you use, if your threat model dictates that. +At the end of the day, although there are a few Perl modules that can +be installed statically, the vast majoirty still rely on executing a +Makefile.PL or Build.PL which is arbitrary Perl code.

+ +

The TL;DR is that if you are an Alien author, or if you are the author +of an Alien::Build plugin you should check to +see if your modules still work when ALIEN_DOWNLOAD_RULE is set to +digest_or_encrypt, which will soon become the new default. This +will require that alienized packages be either

+ +
    +
  • Downloaded using a secure protocol such as https
    • +
  • Checked with a cryptographic signature included in the alienfile (or Build.PL for Alien::Base::ModuleBuild based aliens)
    • +
  • Bundled within the Alien itself.
    • +
+ +

For more details on the security implications please see +Alien::Build::Manual::Secirty.

+ +

I have already gone through all of the plugins that I am aware of and +fixed them. (Unfortunately even plugins that do not modify the +fetch or download stages of L are potentially susceptible +because their tests often need to fake the fetch and download steps +and may do so in a way that seems unsafe to L). I will +also go through all of the aliens that I have control over to make sure +they work with this new default.

+ +

None of this completely removes the peril of downloading arbitrary +software off the internet, but it does improve the default security +model, and gives the end user more control over the security model +via the ALIEN_DOWNLOAD_RULE environment variable.

+ + +
+

+ [ + wdlabs.com | + alienfile.org | + pl.atypus.org | + perlwasm | + uperl + ] + Copyright © 2022 Graham Ollis +

+
+ + diff --git a/docs/blog/index.html b/docs/blog/index.html index 07e3f90..cf06ee1 100644 --- a/docs/blog/index.html +++ b/docs/blog/index.html @@ -22,6 +22,39 @@ +
+

Reining In Unruely Aliens

+ +

By Graham Ollis on 21 September 2022

+ +

When I have talked to Perl developers about the Alien technique, some are +rightly concerned about the security implications of downloading arbitrary +stuff off the internet. My response to this has always to point out that +if you are installing modules from CPAN then you are doing the same.

+ +

In fact the default for one of the most popular cpan clients is to use an +unencrypted http connection to fetch modules off the internet. The default +for the Perl's in core HTTP client is to not verify server identity making +man in the middle attackes much easier. There are historical reasons for +these decisions, but overall I think these are examples of how Perl is +increasingly out of step with the rest of the internet.

+ +

The team responsible for Alien::Build and Alien::Base::ModuleBuild +plan on making it easier for users to control the security model for +downloading and installing alienized packages for Aliens that use them. +We also plan on changing the default model to err on the side of more +secure. None of these changes is a substitue for properly auditing +the open source code that you use, if your threat model dictates that. +At the end of the day, although there are a few Perl modules that can +be installed statically, the vast majoirty still rely on executing a +Makefile.PL or Build.PL which is arbitrary Perl code.

+ +

... read more

+ +
+ + +