[Nix-dev] Malicious installation methods

Adrien Devresse Adev at adev.name
Fri Jun 17 15:17:59 CEST 2016


> The installer, when run, will fetch more code for users to blindly execute (as most of that code will be provided in compiled form). How is blindly running an installer worse than running other code from the same provider?

Simply put the shasum of your installer on the website and ask the user
to verify. That is what many projets do, and it's a three lines of
installation instead of one.


>> PS. There are ways of detecthing when something is piped straight to an
>> interpreter and thus even if someone did curl and read the output and
>> then curled into a shell they could still get infected as serving
>> different pages depending on the circumstances isn't all that
>> difficult.
> This assumes https://nixos.org is already malicious - and then you shouldn't run *anything* that comes from there.
>

The problem is not *ONLY* nixos.org.

Depending of your country and your environment, TLS / HTTPS alone is not
anymore a protocol that you can trust blindly
- https://blog.filippo.io/untrusting-an-intermediate-ca-on-os-x/
-
https://yro.slashdot.org/story/15/12/08/1451239/in-kazakhstan-the-internet-backdoors-you
- https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning



But without even considering that, "curl-pipe-bash" will cause your
sysadmin to blow a fuse or heartbreak in most companies / environments.
And for very good reasons.

Transforming this into a three lines installation script with a simple
"sha256sum -c " verification would not make users run away and would
make the project look more professional.


Adev






Le 17/06/2016 14:07, Tomasz Kontusz a écrit :
>
> Dnia 17 czerwca 2016 13:12:57 CEST, Yui Hirasawa <yui at cock.li> napisał(a):
>> I recently noticed that you recommend very malicious installation
>> methods on your download page for nix[1]
>>
>> Retrieving code straight from the internet and blindly executing is
>> never a good thing and you don't give any sort of recommendation for
>> the
>> user to inspect the script before running it. This completely defeats
>> the point of having reproducible builds when your system can be
>> completely infected when you install the package manager. This also
>> means that anything installed through the package manager is
>> potentially
>> malicious as well.
> The installer, when run, will fetch more code for users to blindly execute (as most of that code will be provided in compiled form). How is blindly running an installer worse than running other code from the same provider?
>
>>> $ curl https://nixos.org/nix/install | sh
>> And this isn't made any better by the fact that you want users to run
>> the script blindly as the superuser.
>>
>>> This script requires that you have sudo access to root,
> The installer needs elevated privileges to do it's job.
>
>> I ask you to PLEASE remove this installation method from the
>> recommendations on the page because it makes it look like you don't
>> care
>> about computer secuirty one bit.
> Now, that's an interesting point. Are there many people who never installed nix because the installer is the recommended installation method?
>
>> PS. There are ways of detecthing when something is piped straight to an
>> interpreter and thus even if someone did curl and read the output and
>> then curled into a shell they could still get infected as serving
>> different pages depending on the circumstances isn't all that
>> difficult.
> This assumes https://nixos.org is already malicious - and then you shouldn't run *anything* that comes from there.
>
>> [1]: https://nixos.org/nix/download.html
>> _______________________________________________
>> nix-dev mailing list
>> nix-dev at lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160617/02f089f0/attachment-0001.sig>


More information about the nix-dev mailing list