Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Python Programming Security

Twelve Malicious Python Libraries Found and Removed From PyPI (zdnet.com) 36

Posted by EditorDavid from the perilous-packages dept.
An anonymous reader writes: A software security engineer has identified 12 Python libraries uploaded on the official Python Package Index (PyPI) that contained malicious code. The 12 packages used typo-squatting in the hopes a user would install them by accident or carelessness when doing a "pip install" operation for a mistyped more popular package, like Django (ex: diango).

Eleven libraries would attempt to either collect data about each infected environment, obtain boot persistence, or even open a reverse shell on remote workstations. A twelfth package, named "colourama," was financially-motivated and hijacked an infected users' operating system clipboard, where it would scan every 500ms for a Bitcoin address-like string, which it would replace with the attacker's own Bitcoin address in an attempt to hijack Bitcoin payments/transfers made by an infected user.
54 users downloaded that package -- although all 12 malicious packages have since been taken down.

Four of the packages were misspellings of django -- diango, djago, dajngo, and djanga.
This discussion has been archived. No new comments can be posted.

Twelve Malicious Python Libraries Found and Removed From PyPI More

Twelve Malicious Python Libraries Found and Removed From PyPI

Comments Filter:
  • Which one, Terry Jones?
  • I've always hated to deal with python in free software game projects because it moves too fast. I've had so many projects where because of old python, part of the project wouldn't work anymore. Its hard when you have a project with two or three developers on it and then now you have all these old python scripts and now they don't work anymore because your distribution upgrades your python. Alright, I don't even know how old it is, but when when you are dealing with these tiny teams of people, you are jus

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      > I've always hated to deal with python in free software game projects because it moves too fast.

      Python 1.0 - January 1994
      Python 2.0 - October 16, 2000
      Python 2.4 - November 30, 2004
      Python 2.6 - October 1, 2008
      Python 3.0 - December 3, 2008

      I think that most likely you started with 2.4 or 2.6.. If we assume that you started with 2.4, in worst case scenario you started coding at 2008, right before 2.6 and 3.0 came out. If you did, in worst case scenario you would end up upgrading first to 2.6 and then to 3.0

      • Re: (Score:2)

        by Baki ( 72515 )

        3.7 is not backwards compatible to 3.6, for example. Last week I had to downgrade...

        We're going to move parts of our python code to go.

    • Lack of compatibility is why I don't like Python (Score:4, Informative)

      by raymorris ( 2726007 ) on Saturday October 27, 2018 @04:04PM (#57546231) Journal

      Same here. Except you don't need "a language I made up", practically any other programming language maintains backward compatibility.

      With Python, when it says "requires Python 2.6â, it means EXACTLY 2.6, not "at least 2.6". Python 2.7 won't work because they completely break compatibility even in point releases. I can't think of any other language that does that.

      I have stuff written in C, Perl, shell, even Javascript fifteen years ago that still runs just fine. Other languages ADD capabilities instead of randomly redefining basic things every year or two.

      • Re: (Score:2)

        by Megol ( 3135005 )

        Swift

      • All the other languages that I can think of that do it are functional academic languages like Haskell.

      • What you say is true, but it's even worse than that. Like you said, it means EXACTLY 2.6. Not even 2.6.1 will work, so if a security issue is found and fixed and patched in Python, you have to recompile your software to fix the issue. Along with abysmal performance, it's one of the most annoying things about supporting Python in production.

        • Re: (Score:1)

          by tartley ( 232836 )
          This is simply wrong. No you do not. I've migrated hundreds of projects through every python transition from 2.6 to 3.7, and never had these problems. I say this with sympathy, not condemnation, because we've all been there in one topic or another, but you must be doing it wrong.

        • Re: (Score:2)

          by tartley ( 232836 )
          > abysmal performance "The performance of uvloop-based asyncio [Python async networking/webserver] is close to that of Go programs." https://magic.io/blog/uvloop-b... [magic.io]

      • Re: (Score:3)

        by sjames ( 1099 )

        You must be doing it wrong. I have literally never had python break due to versioning.

      • Re: (Score:1)

        by Jastiv ( 958017 )
        >I can't think of any other language that does that. I recall issues with Lua and Lua bindings as well.

    • Re:I've always hated Python because... (Score:4, Interesting)

      by DCFusor ( 1763438 ) on Saturday October 27, 2018 @05:25PM (#57546529) Homepage
      Perl 5 - it's been forever since they broke userland - just incremental improvements. No need to worry about rakudo (used to be called perl6) replacing it - it's acknowledged to be a very different language that will never replace 5 for normal production.
      Which I know will get a zillion downvotes, because - with as much flexibility as perl has, some assholes use it to write unreadable code for job security or something. People look at mine and say "oh, how nice you write such clear and obvious code. Is that some better newer C?".
      You can use that rope to shoot yourself in the foot, or pull yourself up. Some people think there shouldn't be more than one way to do it. I like freedom.
      Hint: if you already know python, well, it's more or less a perl copy with crappier namespace and lifetime control, that uses whitespace instead of more civilized {}..and that's about the level of difference. There's even Inline::Python for perl...I use it myself as well as Inline::C. Then there's metacpan...

      • Re: (Score:1)

        by Anonymous Coward

        All the crap they've been writing about perl for the last 15 years... they are now writing about C++.

        Whiners just need to whine. Walking on to a team and finding that the code is downright illegible is like walking into a restaurant and finding you can't determine what the hell is in the salad. Obvious sign you should get up and walk away. Doesn't have anything to do with the language, it has to do with previous people's *use* of the language.

      • Re: (Score:2)

        by DeVilla ( 4563 )

        That's not entirely true. I wish it were. Once they got into the higher 5.teen versions, they started adding features in an attempt to keep up with Perl 6, but they've done it kind of badly.

        There's still a fairly safe sub-set of perl that work pretty well every where. But there have been some advanced changes dubbed 'non-experimental' to later be broken and then removed due to sloppiness while trying to stay 'modern'.

        • Well, yeah. Of course new/experimental stuff is...new, flaky, experimental. Zero of the changes have broken any of my existing code - but of course, if you are an early adopter of anything, you get cut on the bleeding edge some. I code to around 5.10 to 5.20 (rarely the latter). There's a module called "Modern::Perl that lets you require just the features you want by using a version number or year in the require statement. Use it. Try it in new code and find all the places you messed up and used stuff

          • Re: (Score:2)

            by DeVilla ( 4563 )

            I know there'll be issues with experimental stuff and bugs. I was talking about some bigger issues like this one :
            http://blogs.perl.org/users/le... [perl.org]

            I've been noticing a growing number of ill planned changes in perl5 since (roughly) the 5.18 time frame. In that particular case, I think it's nasty that a use statement doesn't protect against the incompatibility. It would break your suggestion of using the use statement. I don't use Modern::Perl because most of the systems I use don't have it, I don'

            • I completely agree. I tend to target something around 5.10 myself and not use some of the maybe-nifty newer features issues since I don't use them. I haven't looked but I wonder if the source for Modern:Perl couldn't just be pasted in...especially if you just want to hold the 5.10 features. I don't use REs heavily at all here. I remember writing one that took around 2-3 days to write and was half a line of code - but it solved a crazy hard problem (sorting vacuum tube numbers the same way humans did for
              • And of course, I'm spoiled because I ALWAYS have root here...I'm lucky to live in a world where computers serve me, not the other way around.

    • I've always hated to deal with python in free software game projects because it moves too fast.

      And here I was exited for the next popular new framework, diango! I thought I was going to generate websites off of dia graphs.

  • This is not something to take lightly (Score:1)

    by Anonymous Coward

    There are several languages/communities that use unsecured repository systems for managing code projects. For example, Composer with PHP. Maintainers are like "oh we'll find it quick if there's a problem", and they don't do anything with it. These are not set up *anything* like linux distribution repositories, for example Ubuntu and RHEL software packages. Problem is, using code signing makes it difficult for people to add their code to the repositories, in other words "to use it" - security hampers adoptio

Slashdot Top Deals

"Pok pok pok, P'kok!" -- Superchicken

Close