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

[Louis Gesbert]

> 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.)

This is already possible, but Linux-only, and requires a local setup (opam 
allows wrappers for package commands, and I wrote some scripts based on Linux 
namespaces to restrict network and FS access. Not quite secure at the moment 
but could be made so). I intended this mainly for CI (and paranoid users), and 
am already using it locally.

> 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.)

My intention was to add a function for this kind of package/repo checks in 
src/state/opamFileTools.ml, taking an additional switch_state as parameter, 
and returning type as `lint`. Then opamMain can (optionally ?) load a state 
and aggregate the results before printing.

Thanks !
Louis


Le Thursday 09 June 2016, 10:57:05 Gabriel Scherer a écrit :
> 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:
> 
> 
> 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.
>