Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Package security #207

Closed
bos opened this Issue · 15 comments

2 participants

Bryan O'Sullivan Johan Tibell
Bryan O'Sullivan
Owner

(Imported from Trac #214, reported by @dcoutts on 2008-01-24)

It'd be nice to avoid getting hacked by a trojaned package.

This task is to:

  • survey the issue
  • consider the threats
  • see what solutions other systems use
  • consider the cost/benefit trade-offs in various security solutions
  • propose something
Bryan O'Sullivan
Owner

(Imported comment by guest on 2008-01-24)

This does seem important. I'll have a look. - svein

Bryan O'Sullivan
Owner

(Imported comment by @dcoutts on 2008-03-10)

demo trojan package

Bryan O'Sullivan
Owner

(Imported comment by @dcoutts on 2008-05-19)

See for example this little demo:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/rmrf
"Delete your home directory during compliation"

It doesn't actually do it of course. It's just a demo.

It's probably been taken down by the time you read this so I've attachd the tarball for reference.

Bryan O'Sullivan
Owner

(Imported comment by ross on 2008-05-19)

I don't appreciate having my time wasted with demonstrations of the bleedin' obvious. I'll delete the username of the next "demonstrator".

Bryan O'Sullivan
Owner

(Imported comment by @dcoutts on 2008-05-19)

We discussed this on #ghc this afternoon. For reference some other obvious ways to make a trojan package are:

  • with build-type Custom using a malicious Setup.hs
  • with build-type Configure using a malicious ./configure
  • with build-type Simple using a malicious custom pre-processor and ghc-options: -F -pgmF dist/build/foo/foo
  • with build-type Simple using ghc-options: -F -pgmFrm -optF-rf
I assume the tricks with ghc options work just as well in {-# OPTIONS #-} pragmas in source files. Then of course there is TH as in today's example which can do arbitrarily bad things, since it has access to IO via runIO and unsafePerformIO.

So clearly it's not sensible to try and patch all these holes just so that we can build (but not run) hostile packages safely, when the obvious way to do that is using OS sandboxing features.

As for users downloading bad packages, perhaps we should ask why they might be more likely to download and run an unknown package from hackage than say 132.73.41.22/hax0r.sh. We should be careful not to give any false sense of security.

Bryan O'Sullivan
Owner

(Imported comment by guest on 2008-05-19)

As for users downloading bad packages, perhaps we should ask why they might be more likely to download and run an unknown package from hackage than say 132.73.41.22/hax0r.sh.

I think cabal install is a fair answer to that question. Together with #239 we have a real security problem, because it makes package names untrustworthy. Password protecting packages as discussed on the libraries list would help there. - int-e

Bryan O'Sullivan
Owner

(Imported comment by guest on 2008-05-20)

I agree with int-e - by putting something on hackage, and telling everyone that hackage is great, we are putting some faith in the system. I think instead of trusting packages, we should be trusting uploaders. There aren't going to be many people who write 3 real Haskell libraries, then on their fourth go, decide to harm everyone. Perhaps a "this person also uploaded", or a cursory check by a human when a person uploads their first package.

Bryan O'Sullivan
Owner

(Imported comment by @dcoutts on 2008-05-20)

I accept that it's bad to be able to subvert an existing named package that has people's trust. #239 is now fixed. I agree that we want a system to let package authors limit who else should be allowed to upload their package.

Linking authors to what else they have uploaded is also a good idea.

My point was about a new package that someone uploaded as in the recent demo and that that's not so much of a problem precisely because its new. We expect people to download packages they know of or have had recommended, not random packages.

Bryan O'Sullivan
Owner

(Imported comment by guest on 2008-05-20)

I worry about the idea of providing "security" or some notion of safety or trust only if one behaves "as expected". That seems slightly odd to me.

Secondly, there has to be a first person or a first five people that grab the package to try it out and to give it its initial "rating". And those five could be 500 if it's suitably advertised, an oft requested feature or a popular idea. Try adding a package to Hackage that claims it adds a dependently typed system to Haskell and watch the number of downloads! And if such a package as that is trojaned... -- matthew

Bryan O'Sullivan
Owner

(Imported comment by ross on 2008-05-20)

Replying to @dcoutts:

I accept that it's bad to be able to subvert an existing named package that has people's trust. #239 is now fixed. I agree that we want a system to let package authors limit who else should be allowed to upload their package.

#239 is only fixed in that you cannot replace an existing version, and the uploader is displayed on the package page. It remains possible for anyone to upload a new version of any package. I've been assuming that I'm dealing with responsible people, and will remove any that aren't.

People seem very keen to jump to the last item on your list above. Most security measures have costs to implementors, users and in maintenance. If they cover only some of the holes, they will be worse than useless: the system will be harder to use and maintain, but no more secure.

Linking authors to what else they have uploaded is also a good idea.

This would be useful, and tied in with build reporting would give some sort of ranking of package maintainers, and may motivate them to test their packages before uploading them. I'm not sure it would help a lot with security, though.

Bryan O'Sullivan
Owner

(Imported comment by guest on 2008-05-20)

Replying to myself:

Password protecting packages as discussed on the libraries list

Actually I liked the idea of limiting the uploaders of packages better, because it has a smaller impact on the authors' workflow, and paves the way for trusting packages by their base name (which is what cabal-install uses to find packages.)

In a way it's similar to what CPAN does. They force their authors to register the namespace they are going to use, and their package names are tied to the namespace. (http://www.cpan.org/modules/04pause.html) They also have co-maintainers for packages, and they require admin intervention for taking over orphaned packages. (http://www.nntp.perl.org/group/perl.cvs.perlfaq/2007/07/msg393.html) - int-e

Bryan O'Sullivan
Owner

(Imported comment by ross on 2008-05-20)

Replying to guest:

Replying to myself:
Password protecting packages as discussed on the libraries list

Actually I liked the idea of limiting the uploaders of packages better, because it has a smaller impact on the authors' workflow, and paves the way for trusting packages by their base name (which is what cabal-install uses to find packages.)


I suspect that Bulat, who proposed that, didn't realize that we have password authentication for users.

There may be an inevitable logic to what you say. Still, there's only been one case so far of someone overwriting a package, and that wouldn't have happened if we had had a policy on display. Almost all of the problems so far have been with the first upload (by a non-maintainer), and this machinery wouldn't help there, but would make it worse.

Bryan O'Sullivan
Owner

(Imported comment by @dcoutts on 2008-05-20)

Replying to guest:

I worry about the idea of providing "security" or some notion of safety or trust only if one behaves "as expected". That seems slightly odd to me.

I think it's really essential. You are expecting for some reason that something on hackage is held to a higher security or QA standard than something else you randomly download off the web. What gives you that confidence? What makes you think other users have that confidence? Perhaps that's the security problem. There's no security problem with 132.73.41.22/hax0r.sh because there's no reason you would expect to trust it.

As I said, a name can establish a reputation so there is value in preventing well known names from being subverted.

Bryan O'Sullivan
Owner

(Imported comment by guest on 2008-05-20)

Replying to @dcoutts:

Replying to guest:
I worry about the idea of providing "security" or some notion of safety or trust only if one behaves "as expected". That seems slightly odd to me.

I think it's really essential. You are expecting for some reason that something on hackage is held to a higher security or QA standard than something else you randomly download off the web. What gives you that confidence? What makes you think other users have that confidence? Perhaps that's the security problem. There's no security problem with 132.73.41.22/hax0r.sh because there's no reason you would expect to trust it.


I'm not sure we're disagreeing, I think we're just talking about different things. You say "We expect people to download packages they know of or have had recommended, not random packages." I'm trying to say that the only way in which code can migrate from "random package" status to "known and/or recommended" status is precisely by people downloading random packages.
As I said, a name can establish a reputation so there is value in preventing well known names from being subverted.

Yes, absolutely, except without the "well known" bit. -- matthew

Johan Tibell
Owner

Closing as there's been no activity in years.

We're cleaning up the bug tracker to make it useful again and are thus closing bugs that haven't seen any activity in a long time. Please re-open (or file a new bug) if the problem reappears.

Johan Tibell tibbe closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.