[opam-devel] "Typosquatting programming language package managers"; how to protect opam-repository from typo-squatting?

Roberto Di Cosmo roberto at dicosmo.org
Thu Jun 9 18:39:51 BST 2016

Thanks Gabriel,
       this is another cool related work to add to the long list of
readings for who is interested in package management.

On Thu, Jun 09, 2016 at 10:57:05AM -0400, Gabriel Scherer wrote:
> Hi opam-devel,
> Here is a rather cool bachelor thesis that seems relevant to OPAM repository
> management:
>   Typosquatting in Programming Language Package Managers
>   Nikolai Philipp Tschacher, March 2016
>   http://incolumitas.com/2016/06/08/typosquatting-package-managers/
> The described attack is to propose packages whose names are typo-close to very
> popular packages. Instead of "opam install omake" I run "opam install omaek",
> but "omaek" exists and is attacker-controlled, and its install script wreaks
> havoc on my machine.
> This is interesting because it is a way to subvert a specific package that is
> immune to the common defenses against impersonation -- signing a package with
> its maintainers keys, etc. The author of the thesis suggests three defense
> methods:
> 1. Make package installation sandboxed in such a way that just installing a
> package is harmless as long as its code is not linked and run. (Of course this
> code may be linked and run if a developer also makes a typo in its software.)
> 2. Alert repository administrators when a typo-candidate is proposed for
> integration. (This is especially relevant for repositories with no human
> oversight on package addition, but even for OPAM one may consider that the
> maintainers themselves may be fooled by the typo or not think of the security
> consequences.)
> 3. Keep a log of the non-existing packages that users commonly try to install
> (good candidates for typos) and alert administrators when a matching package is
> proposed.
> I'm sure that the systems expert in the room have plans for (1) already. I
> suspect that opam's architecture does not let us do (3), but I was interesting
> in quickly hacking (2) this morning -- I suppose I like typo-detection stuff.
> My plan was: in `opam lint`, emit a warning if the linted package name is at
> edit distance 2 or less (but not 0) of an existing package in the repository.
> But this does not quite work; I quickly looked at the code and it seems that
> "opam lint" is meant to be run purely locally, it does not have access to a
> base of packages available in the repository.
> So my question: where in the opam-repository QA process should I add a script
> (preferably written in OCaml rather than shell) that gets the name of the
> packages proposed for inclusion, also has access to the name of existing
> packages in the repository, and can fail or warn if the proposed one is
> typo-close to an existing one?
> (This test can have false positives, eg. installing lablgtk2 when lablgtk
> exists. It should still fail in a visible way in the UI, but not in a way that
> prevent other, more advanced tests, such as package installability.)

> _______________________________________________
> opam-devel mailing list
> opam-devel at lists.ocaml.org
> http://lists.ocaml.org/listinfo/opam-devel

Roberto Di Cosmo
Professeur (on leave at/detache a INRIA Roquencourt)
IRIF                          E-mail : roberto at dicosmo.org
Universite Paris Diderot         Web : http://www.dicosmo.org
Case 7014                    Twitter : http://twitter.com/rdicosmo         
5, Rue Thomas Mann       
F-75205 Paris Cedex 13 France  
Office location:

Paris Diderot	 		    INRIA
Bureau 3020 (3rd floor)             Bureau C123
Batiment Sophie Germain             Batiment C
8 place Aurélie Nemours             2, Rue Simone Iff
Tel: +33 1 57 27 92 20              Tel: +33 1 80 49 44 42 

  Bibliotheque F. Mitterrand        Ligne 6: Dugommier
  ligne 14/RER C                    Ligne 14/RER A: Gare de Lyon
GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3                        

More information about the opam-devel mailing list