To check a few you different requirements.txt files (will look 3 folders deep)
find . -maxdepth 3 -name requirements.txt | xargs egrep '^(acqusition|apidev-coop|bzip|crypt|django-server|pwd|setup-tools|telnet|urlib3|urllib)'
Malicious software libraries found in PyPI posing as well known libraries
141–150 of 254 posts
Re: Malicious software libraries found in PyPI posing as well known libraries
#142Earlier quoted context omitted.
Authors don't generate distro packages because there's too many distros and each distro needs to make changes that have nothing to do with code. Maintainers are necessary and a package signed by the author is a non-starter. However, source code can be signed and then used to make a package signed by a distro.
Think of it instead of allowing access to the system to maintain packages, we allow people to submit code that generates packages.
Of course you can do this - all packages are basically just wrappers around upstream code. But you still need someone to maintain the wrapper, and they have to check every new code release to see if there's something in the wrapper that has to change. And there are multiple distros. There's no getting away from maintainers with traditional linux distros.
Code package management is different. The author writes their software specifically to conform to the one code package management system. There's no wrapper glue needed, so you don't need a maintainer. Just release your new code and it fits into the system, and other code/tools/etc can just pick it up and use it.
This works if you constantly update all the software you use everywhere, and is pretty much guaranteed to become a nightmare if you don't. CPAN is probably the most mature software package management system in existence and it's still a nightmare if you don't keep a private repo and tightly manage releases, and you absolutely need a maintainer.
Re: Malicious software libraries found in PyPI posing as well known libraries
#143Earlier quoted context omitted.
Sure its nice (and easier) to use the distro's package management system, but it often just isn't up to date enough. You end up using thing that are a while out of date and may have security flaws as a result.
> using thing that are a while out of date and may have security flaws as a result On the contrary, on distributions that perform security updates the level of security of a package can only increase over time. It might sound obvious but vulnerabilities are created in new releases, while vulns in existing packages can be only be found and fixed, not created. (Of course I'm talking only about vulnerabilities here and…
I would just like to point out that a "fix" for a vulnerability does occasionally introduce others.
Re: Malicious software libraries found in PyPI posing as well known libraries
#144Do not forget their password that worked for couple of years: nbuSR123 ...
Re: Malicious software libraries found in PyPI posing as well known libraries
#145To check a few you different requirements.txt files (will look 3 folders deep) find . -maxdepth 3 -name requirements.txt | xargs egrep '^(acqusition|apidev-coop|bzip|crypt|django-server|pwd|setup-tools|telnet|urlib3|urllib)'
Avoid some false positives
pip list --format=legacy | cut -d' ' -f1 | xargs egrep '^(acqusition|apidev-coop|bzip|crypt|django-server|pwd|setup-tools|telnet|urlib3|urllib)$'
Re: Malicious software libraries found in PyPI posing as well known libraries
#146The regex they have for identifying fake/harmful packages is wrong. `pip list –format=legacy | egrep '^(acqusition|apidev-coop|bzip|crypt|django-server|pwd|setup-tools|telnet|urlib3|urllib) '` This incorrectly lists `urllib3` or the `cryptography` package for example, which are perfectly valid packages. [UPDATE] Read "tobltobs" comment below. I incorrectly removed a trailing space from the regex.
pip list --format=legacy | cut -d' ' -f1 | xargs egrep '^(acqusition|apidev-coop|bzip|crypt|django-server|pwd|setup-tools|telnet|urlib3|urllib)$'
Re: Malicious software libraries found in PyPI posing as well known libraries
#147to see if you have any of these deps on your python path: pip list –format=legacy | egrep -e '^acqusition$' -e '^apidev-coop$' -e '^bzip$' -e '^crypt$' -e '^django-server$' -e '^pwd$' -e '^setup-tools$' -e '^telnet$' -e '^urlib3$' -e '^urllib$' to see if you have any projects in a given directory that require them: cat $(find /path/to/dir -name 'requirements.txt') | egrep -e '^acqusition==' -e '^apidev-coop==' -e '^b…
pip list --format=legacy | cut -d' ' -f1 | xargs egrep '^(acqusition|apidev-coop|bzip|crypt|django-server|pwd|setup-tools|telnet|urlib3|urllib)$'
Re: Malicious software libraries found in PyPI posing as well known libraries
#148Package managers seem to be an increasingly popular attack vector. It's only luck that none of the attacks have been particularly malicious yet. Considering how many package manager downloads go to a server in a datacenter, a widely distributed malicious package could control a botnet with extremely high throughput, or wreak havoc on any databases it comes into contact with. It's only a matter of time before somethin…
Another fun fact to consider is that with many package formats, you can execute arbitrary code at install time so if a malicious package can get into a repository, it's very likely to start compromising systems quickly. Whilst a package manager repo. compromise would be the biggest bang in terms of attack, compromising the credentials of the developers of popualar libraries would be an easier attack (and indeed is al…
Doubly so since when installed on a server very often it will be done as "sudo pip install ....." (/s/pip/other-package-manager/ as needed)
Re: Malicious software libraries found in PyPI posing as well known libraries
#149Earlier quoted context omitted.
Think of it instead of allowing access to the system to maintain packages, we allow people to submit code that generates packages.
Of course you can do this - all packages are basically just wrappers around upstream code. But you still need someone to maintain the wrapper, and they have to check every new code release to see if there's something in the wrapper that has to change. And there are multiple distros. There's no getting away from maintainers with traditional linux distros. Code package management is different. The author writes their s…
To be clear, what I'm suggesting is to generate those wrappers automatically, instead of maintaining them manually. A script can visit a release page daily, parse it and check for updates. If there is a new upstream release, it can generate a wrapper and let the build system do the rest, produce binaries, test them, etc. When things break, the code needs to be fixed, but it's definitely very far from every release. And you don't have to trust the maintainer of that script anymore or even have a separate maintainer, everything could be reviewed on pull requests with only a small group of people having commit rights to the repository.
Re: Malicious software libraries found in PyPI posing as well known libraries
#150Maybe packages should be signed by several trusted maintainers. Or, noticing PyPI packages list a source code link on github sometimes, along those lines, there can be a process to prove ownership of some known online identity, keybase style. Unpopular packages can also be flagged, especially one that has a near twin that is much more popular. There are many solutions.