
Devs unknowingly use “malicious” modules snuck into official Python repository - zymhan
https://arstechnica.com/information-technology/2017/09/devs-unknowingly-use-malicious-modules-put-into-official-python-repository/
======
zizek23
The casual culture of pulling in hundred of dependencies, and mushrooming
language specific package managers is ridiculously insecure and has to go.

There is no way for anyone to know what all this code is doing, there is
little way to verify updates and its simply untenable.

If some developers like this sort of unsafe practice it should be strictly
limited to their machines and in no way make it across in any form as a
deployment artifact.

There are already secure distribution package managers with the necessary
infrastructure, you are not special, use those. Ruby is already paying a price
for imposing dependency hell of users and wasting millions of man hours. Many
have suffered and do not even bother with Ruby apps anymore. Node and others
who think this is a good model will be next. Users should simply boycott such
user hostile developers and languages that encourage this kind of insecurity.

~~~
yeukhon
Everything we do in life relies on a trust system more or less. Reproducible
build only guarantees integrity, not the trustworthiness of the code.

> There is no way for anyone to know what all this code is doing, there is
> little way to verify updates and its simply untenable.

Because few people have time to read source code. Take Django as an example.
Big community, lots of contributors. Can we say we should trust the code
because the number of eyes? Probably, but not always.

Why? We can overlook and pretend the code is legitmate. Take Linux kernel or
some of the crypto projects out there. A lot of unreadable old tricks made
backdoor really easy. [1] is interesting because someone apparently made an
authorized changeset to BitKeeper. Are you going to read JRE code to make sure
no backdoor? Nah.

Is there a solution? Nope and will never have a solution. The best one can do
is using a DVCS to prevent unathorized changeset (provided every contributor
does a sanity check for pulling in changeset) and trust the community. No
machine can distinugish a good code from a bad code. Humans can't even tell
unless raising a red flag.

Sometimes change of project ownership can also introduce some uncertainty, but
that is a rare case for major projects.

I am pretty confident there are code in the Linux kernel no one has ever
touched or ever read for years.

[1]: [https://freedom-to-tinker.com/2013/10/09/the-linux-
backdoor-...](https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-
attempt-of-2003/)

~~~
rlpb
Distributions - let's take Debian as a concrete example - provide an audit
trail to individual identified developers as a mitigation for users relying on
trust. Just because we must necessarily rely on some level of trust does not
mean that we must blindly trust, which is what happens when anyone can upload
to a repository such as PyPI.

~~~
yeukhon
As far as I know, once the project name is taken, that ownership belongs to
the account first created this package in PyPI.

------
userbinator
The IP address it phones home to, 121.42.217.44, is located in China and
visiting it with HTTP just displays this interesting message:

    
    
        Hi bro :)
    
        Welcome Here!
    
        Leave Messages via HTTP Log Please :)
    
    
        On 2017-09-16:
    
        Happy to see somebody find it ! :)
    
        Just curious about how long it would take for people to find those 'bad' packages
    
        As you see, that's just a toy script, no harm, hope you enjoy it !
    

It looks like someone (security researcher?) just set up a PoC and didn't
intend to actually "weaponise" it.

~~~
sametmax
It may be [https://pytosquatting.org/](https://pytosquatting.org/). In that
case it was indeed a harmless and quite useful PoC.

~~~
hannob
No. (Co-operator of pytosquatting here)

While our code was similar in nature, it was non-obfuscated and we always
threw an exception telling the user that he installed something he shouldn't.

~~~
skrause
But you still call an URL first, e.g.
[https://www.pytosquatting.org/pingback/pypi/urllib2/](https://www.pytosquatting.org/pingback/pypi/urllib2/)
for "urllib2" before raising the exception. Though it is not an IP in China
and only returns the text "Pingback from package urllib2 in repository pypi".

------
swiley
One nice thing about languages like C is that a lot of programmers just avoid
dependencies because dealing with them kind of sucks. That's one solution to
this problem.

~~~
sametmax
Yeah this way you reinvent a less unit tested, battle field tested and
documented wheel.

It's like saying the good thing with not having a cellphone is that you avoid
a lot of fight with your girlfriend cause you can't talk as much.

~~~
dom0
> It's like saying the good thing with not having a cellphone is that you
> avoid a lot of fight with your girlfriend cause you can't talk as much.

I can't quite see what's wrong with that...

~~~
tokenizerrr
Do you have a cellphone? If so, throw it into the trash right now.

~~~
swiley
I would if I had a girlfriend and she was ok with it. I feel like it's hard to
date without one which really sucks.

------
js2
FYI: "Malicious software libraries found in PyPI posing as well known
libraries"

[https://news.ycombinator.com/item?id=15256121](https://news.ycombinator.com/item?id=15256121)

(2 days ago, 465 points, 245 comments)

------
stestagg
This is a rehash of: [https://hackernoon.com/building-a-botnet-on-pypi-
be1ad280b8d...](https://hackernoon.com/building-a-botnet-on-pypi-be1ad280b8d6)

Interestingly, my fake system packages have been downloaded about 480 000
times so far this year

~~~
scaryclam
Ouch, and thanks for being proactive getting those names squatted

------
camus2
Well pip has the same problem as NPM : no namespaces by default.

But NPM is worse with all its dependencies of dependencies. Composer (PHP) got
both namespace and dependencies right: flat dependencies, it's up to the
developer to resolve conflicts, not to the package manager to create insane
dependency trees.

It leads to more stable packages and make spotting fakes easier.

~~~
Can_Not
I'd say pip is definitely worse. Things like local dependencies,
requirements.txt, and virtual env feel hacked add-ons to make pip more like
npm

------
jlgaddis
Original advisory (including fake packages): [http://www.nbu.gov.sk/skcsirt-
sa-20170909-pypi/](http://www.nbu.gov.sk/skcsirt-sa-20170909-pypi/)

------
nonbel
The other day, I was using rmarkdown and noticed that every time it ran it
tried to source this:

[https://mathjax.rstudio.com/2.7.2/MathJax.js?config=TeX-
AMS-...](https://mathjax.rstudio.com/2.7.2/MathJax.js?config=TeX-AMS-
MML_HTMLorMML)

This was really disconcerting since I did not expect to be downloading
anything, let alone running javascript from there just to make a chart.

------
lifeisstillgood
I think there is a value in upgrading the cheeseshop to use "verified
maintainers" \- it should be simple to do a first pass of "the person who
signed the hash of this module has also verified they own the domain
requests.kreitz.org by publishing that public key at that domains root"

Even more useful might be domain/keys/kreitz/publickeylisting

The key signing party is much harder to arrange but is easier to be confident
about

Personally I am surprised the Post Office does not do key signing

Edit: I thought pip did do cryptographic checks?!

~~~
falsedan
> _I think there is a value in upgrading the cheeseshop to use "verified
> maintainers" \- it should be simple to do a first pass of "the person who
> signed the hash of this module has also verified they own the domain
> requests.kreitz.org by publishing that public key at that domains root"_

That sounds useless. An attacker could verify that they own evilattacker.com &
publish their malicious packages there.

I don't think a web of trust is the answer here, because it doesn't really
matter if the attack is anonymous or not, and if only trusted people can
publish packages, trust will be given more readily to encourage new
programmers to contribute.

I think a reputation/review system is better, like docker search's star count,
or metacpan's ++ rating.

------
rajangdavis
How do you check if you are affected?

~~~
jp_sc
The list is in the advisory. Check if you have installed any of these:

    
    
      – acqusition (uploaded 2017-06-03 01:58:01, impersonates acquisition)
      – apidev-coop (uploaded 2017-06-03 05:16:08, impersonates apidev-coop_cms)
      – bzip (uploaded 2017-06-04 07:08:05, impersonates bz2file)
      – crypt (uploaded 2017-06-03 08:03:14, impersonates crypto)
      – django-server (uploaded 2017-06-02 08:22:23, impersonates django-server-guardian-api)
      – pwd (uploaded 2017-06-02 13:12:33, impersonates pwdhash)
      – setup-tools (uploaded 2017-06-02 08:54:44, impersonates setuptools)
      – telnet (uploaded 2017-06-02 15:35:05, impersonates telnetsrvlib)
      – urlib3 (uploaded 2017-06-02 07:09:29, impersonates urllib3)
      – urllib (uploaded 2017-06-02 07:03:37, impersonates urllib3)

~~~
rajangdavis
Really close call (I have the correct version of setuptools installed which is
what had me worried).

