6 ms·

Simple but probably wrong solution; why not ban obfuscation libraries, compressed and self-loading code within the PyPI ecosystem. Any package that even refers

Simple but probably wrong solution; why not ban obfuscation libraries, compressed and self-loading code within the PyPI ecosystem. Any package that even refers to illegible non-source techniques gets flagged and blocked? It seems the whole PyPI ecosystem is undisciplined and could be tightened up. Why can't we progress here?

anothernewdude 4y ago
Yeah, just get rid of anything that has a binary blob. Cool. And then when PyPI gets swapped out for whatever immediately replaces it because PyPI is useless, then at least PyPI will be secure.
- nonrandomstring 4y ago
  > PyPI is useless Why will it be "useless". Explain your reasoning please.
  - pletnes 4y ago
    Most of the libraries I use include compiled C/C++/Fortran/Rust code. Pandas, scipy, scikit-learn, … if I were limited to pure-python libraries, I would probably rather swap languages, or at least package manager, at great inconvenience. That being said, I don’t think PyPI would be «useless» - this was the state a few years ago, and we had to compile all the libraries ourselves. I don’t want to go back.
    - nonrandomstring 4y ago
      > great inconvenience It's a convenience/security trade-off, I see. The only solution I've ever seen to that requires investing trust in an "authority" which then becomes corrupt and censorial. One simply expands the dilemma to a triad; security/freedom/convenience. If I am not mistaken the PyPI "Cheese Shop" is owned by the Python Software Foundation, a 501(c3) nonprofit organisation which constitutionally values Software Freedom highly. It seems natural that convenience would be sacrificed if security is of concern.
      - nine_k 4y ago
        Such an authority in the Linux world used to be a distribution. Installing a binary blob provided by Debian build servers is based on decades of trust. But there is a tradeoff between having things thoroughly vetted and tested, and moving fast.
        nonrandomstring 4y ago
        Interesting point. So as dimensions we now have - security - freedom - convenience - speed/newness Who can build me a UI with four sliders that selects the packages I can install? Bonus: when I move a slider it highlights all the potential packages that changed status with reasons why they are now included/excluded.
        dylan604 4y ago
        You're an HN reader, so you should be able to knock this out over a weekend /s
        nonrandomstring 4y ago
        You're right the prototype GUI is a weekend of work. But you also know that's not where the work is :) Now some more intelligent comments are coming in we can talk about the analysis and tagging of thousands of packages, dealing with backward compatibility and what happens when naughty malware just hops to another level of trust. But none of that is a call to give up. We just need to think seriously about the problem we face.
    - zzzeek 4y ago
      None of those packages are downloading and running CRAP.EXE within the setup.py process, that's not how native extensions work. It should be possible to flag packages that are downloading things when setup.py runs, much less running exec within setup.py. a python package that really needs you to run a windows installer for its dependencies should have you be doing that separately.
      - pletnes 4y ago
        Sure, I didn’t intend to claim that. It’s just a hassle for me to compile my own C code, which I’d have to do if binaries weren’t bundled. That’s why anaconda python took off on windows - it’s hard work to compile scipy on windows!
        zzzeek 4y ago
        pypi delivers wheel files for pre-built binaries, and that's the only way one is supposed to distribute pre-built binary executables or shared libraries. the issue of "runs malicious code in setup.py" does not apply in that case because setup.py isn't invoked.
      - BiteCode_dev 4y ago
        Yes but the problem here is the obfuscation of the malware code loading. No need to trigger it in the setup.py process, as long as you have it in the lib, you can always put a call in a .pth somewhere and run your malware as soon as any python is executed.
        zzzeek 4y ago
        it should be possible to test packages for that also. if you are testing setup.py to see that no network access or exec occurs, you could similarly run the python interpreter after install and ensure no network / exec() happens at that point either, assuming one has not imported the package. or just disallow unfamiliar .pth files from being installed altogether (outside of those generated by setuptools / etc. for normal execution).
    - harlanji 4y ago
      Windows S Mode has PyPI restricted to pure Python due to Device Guard. I'm happy to leave it on ($250 laptop). Indeed, Numpy has been a recurring blocker, maybe 3 times now. But with general peace of mind is the only way I've known Python/PyPI, so I'm pretty happy with it. I have a few RasPis that I can use as auxiliary devices as well, which I think is a pretty cool tradeoff, hardware sandbox--not gone there yet, beyond just configuring SSH/xRDP so I'm ready if the day comes. But I've made a ton of web apps and tools anyway, including a little process launcher that plays the role of poor man's Docker. It'd be nice if those popular systems had a pure Python capability anyway, similar analogy being software rendered 3D back in the day.
- danuker 4y ago
  For instance, F-Droid only permits software that can be verifiably compiled by them. It essentially bans binary blobs yet it is very useful.
  - turminal 4y ago
    F-droid also has very different goals and lives in a much smaller and in some ways much saner ecosystem.
  - baeaz 4y ago
    F-Droid is infamously known for taking weeks to build a new version of any app.
    - yjftsjthsd-h 4y ago
      I'm given to understand that's more about having an offline signing process then the actual builds.
  - BiteCode_dev 4y ago
    Yes, but pypi has 4 millions release to check, and the scientific and machine learning wheels are very hard to compile (scipy contains c, fortran and assembly code, and must be compiled to mac, linux and windows). Providing a build env for that would make it prohibitively complicated and expensive, and basically would mirror github CI. That's the reason continuum is making money: they sell a python package distribution channel that is checked and locked.
- lalaland1125 4y ago
  A simple warning when a library adds a binary blob should be enough. You don't need to ban them entirely.
stingraycharles 4y ago
I don’t think this would work well for shipping packages that use proprietary libraries. But at the very least they could be flagged, yes.
meltyness 4y ago
Are they to test this condition for each input to each program?
kortex 4y ago
Self-loading code is a huge part of the value-add of python libraries. Many of the popular libraries (e.g. Numpy and friends) trigger a bewildering chain of events to compile from source if not installing from pre-built wheels. And if you do have wheels, you have opaque binary blobs. So pick your poison: compile-on-install with possible backdoor or prebuilt .so/.dylib/.pyc with possible backdoor. The most obvious (but not necessarily easiest) approach is to phase out setup.py and move everything to the declarative pyproject.toml approach. This is not just better for metadata (setup scripts make it really hard to statically infer what deps a lib has), it also allows for better control over what installers/toolchains run on install. Attackers still have quite a lot of latitude during the build phase, but at least libraries have the option to specify declaratively what permissions they need (and presumably the user has the option to forbid them). Also eval/exec are terrible and I wish there were a mode to disable their usage, but I don't know if the python runtime has some deep dependency on it. Maybe there's a way to restrict it so that only low level frames can call the eval opcode.
- beardog 4y ago
  >Also eval/exec are terrible and I wish there were a mode to disable their usage, You can use audit hooks in the sys module (as long as you load it first) to disable eval/exec/process spawning or even arbitrary imports or network requests.
- fn-mote 4y ago
  Would it be possible that the wheels could be built in a more-trusted / hardened environment? Having a binary blob isn't as serious when it comes from a trusted source. Almost all Debian/etc linux distributions have this feature (binary-downloading package manager). The hardening could mitigate on-compilation hacking. Obviously, this leaves "compile in the backdoor and wait for the user to fall into it" but at least this isn't an issue of compiling on the user's computer and it isn't a issue of binary blobs. And possibly there's a greater chance of detection if actual source code has to be available to compile.
woodruffw 4y ago
The short answer is that this can’t be easily mitigated at the package index level, at least not without massive breaking chances to the Python packaging ecosystem: PyPI would have to ban all setup.py based source distributions. Even then, that only pushes the problem down a layer: you’re still fundamentally installing third party code, which can do whatever it pleases. The problem then becomes one of static analysis, for which precision is the major limitation (in effect, just continuing the cat-and-mouse game.)
BiteCode_dev 4y ago
You can pip install complex stand alone executables, such as nodejs, and it's used in the entire ecosystem. In fact, most packages are now wheels, which are not sources: they are compressed, and may contain binaries for compiles extensions, something extremely popular (the scientific and AI stacks exist only because of this). Some packages need to be compiled after the fact, something that setup.py will trigger, and some even embed a fallback compiler, like some cython based packages. Also, remember there is very few people working on pypi, there is no moderation, anybody can publish anything, so you would need a bullet proof automated heuristic. That's either impractical, or too expensive. If you want a secure package distribution platform, there are commercial ones, such as anaconda. You get what you pay for.
- ThePowerOfFuet 4y ago
  I guess we're finding out the other side of that blade, huh?
weakfortress 4y ago
Even simpler solution: Require cryptographic signatures of the developers of projects along with hash-verified downloads via pip. The problem is a failure to understand security.
- Blackthorn 4y ago
  Requiring anything from open source authors is a losing proposition. Items of interest just won't end up on pypi. Iirc this chain of events already happened on another distribution platform.
- anakaine 4y ago
  A malicious author could embed malicious code in the package and still get the package signed. Hashing won't prevent this sort of thing on PyPi, it just addresses in transit and alternate supplier attacks.
ashishbijlani 4y ago
I’ve been building Packj [1] to flag PyPI/NPM/Ruby packages that contain suspicious decode+exec and other “risky” APIs using static analysis. It also uses strace-based dynamic analysis to monitor install-time filesystem/network activities. We have detected a bunch of malware with the tool. 1. https://github.com/ossillate-inc/packj https://github.com/ossillate-inc/packj flags malicious/risky packages.
_8j50 4y ago
Why would you think that would change a thing? Also, obfuscation has legitimate uses by people making stuff they don't want easily reversed. This isn't a python specific problem.
anony23 4y ago
They can just load the real payload as a second stage.

anothernewdude 4y ago

Yeah, just get rid of anything that has a binary blob. Cool. And then when PyPI gets swapped out for whatever immediately replaces it because PyPI is useless, then at least PyPI will be secure.

nonrandomstring 4y ago
> PyPI is useless Why will it be "useless". Explain your reasoning please.
- pletnes 4y ago
  Most of the libraries I use include compiled C/C++/Fortran/Rust code. Pandas, scipy, scikit-learn, … if I were limited to pure-python libraries, I would probably rather swap languages, or at least package manager, at great inconvenience. That being said, I don’t think PyPI would be «useless» - this was the state a few years ago, and we had to compile all the libraries ourselves. I don’t want to go back.
  - nonrandomstring 4y ago
    > great inconvenience It's a convenience/security trade-off, I see. The only solution I've ever seen to that requires investing trust in an "authority" which then becomes corrupt and censorial. One simply expands the dilemma to a triad; security/freedom/convenience. If I am not mistaken the PyPI "Cheese Shop" is owned by the Python Software Foundation, a 501(c3) nonprofit organisation which constitutionally values Software Freedom highly. It seems natural that convenience would be sacrificed if security is of concern.
    - nine_k 4y ago
      Such an authority in the Linux world used to be a distribution. Installing a binary blob provided by Debian build servers is based on decades of trust. But there is a tradeoff between having things thoroughly vetted and tested, and moving fast.
      - nonrandomstring 4y ago
        Interesting point. So as dimensions we now have - security - freedom - convenience - speed/newness Who can build me a UI with four sliders that selects the packages I can install? Bonus: when I move a slider it highlights all the potential packages that changed status with reasons why they are now included/excluded.
        dylan604 4y ago
        You're an HN reader, so you should be able to knock this out over a weekend /s
        nonrandomstring 4y ago
        You're right the prototype GUI is a weekend of work. But you also know that's not where the work is :) Now some more intelligent comments are coming in we can talk about the analysis and tagging of thousands of packages, dealing with backward compatibility and what happens when naughty malware just hops to another level of trust. But none of that is a call to give up. We just need to think seriously about the problem we face.
  - zzzeek 4y ago
    None of those packages are downloading and running CRAP.EXE within the setup.py process, that's not how native extensions work. It should be possible to flag packages that are downloading things when setup.py runs, much less running exec within setup.py. a python package that really needs you to run a windows installer for its dependencies should have you be doing that separately.
    - pletnes 4y ago
      Sure, I didn’t intend to claim that. It’s just a hassle for me to compile my own C code, which I’d have to do if binaries weren’t bundled. That’s why anaconda python took off on windows - it’s hard work to compile scipy on windows!
      - zzzeek 4y ago
        pypi delivers wheel files for pre-built binaries, and that's the only way one is supposed to distribute pre-built binary executables or shared libraries. the issue of "runs malicious code in setup.py" does not apply in that case because setup.py isn't invoked.
    - BiteCode_dev 4y ago
      Yes but the problem here is the obfuscation of the malware code loading. No need to trigger it in the setup.py process, as long as you have it in the lib, you can always put a call in a .pth somewhere and run your malware as soon as any python is executed.
      - zzzeek 4y ago
        it should be possible to test packages for that also. if you are testing setup.py to see that no network access or exec occurs, you could similarly run the python interpreter after install and ensure no network / exec() happens at that point either, assuming one has not imported the package. or just disallow unfamiliar .pth files from being installed altogether (outside of those generated by setuptools / etc. for normal execution).
  - harlanji 4y ago
    Windows S Mode has PyPI restricted to pure Python due to Device Guard. I'm happy to leave it on ($250 laptop). Indeed, Numpy has been a recurring blocker, maybe 3 times now. But with general peace of mind is the only way I've known Python/PyPI, so I'm pretty happy with it. I have a few RasPis that I can use as auxiliary devices as well, which I think is a pretty cool tradeoff, hardware sandbox--not gone there yet, beyond just configuring SSH/xRDP so I'm ready if the day comes. But I've made a ton of web apps and tools anyway, including a little process launcher that plays the role of poor man's Docker. It'd be nice if those popular systems had a pure Python capability anyway, similar analogy being software rendered 3D back in the day.
danuker 4y ago
For instance, F-Droid only permits software that can be verifiably compiled by them. It essentially bans binary blobs yet it is very useful.
- turminal 4y ago
  F-droid also has very different goals and lives in a much smaller and in some ways much saner ecosystem.
- baeaz 4y ago
  F-Droid is infamously known for taking weeks to build a new version of any app.
  - yjftsjthsd-h 4y ago
    I'm given to understand that's more about having an offline signing process then the actual builds.
- BiteCode_dev 4y ago
  Yes, but pypi has 4 millions release to check, and the scientific and machine learning wheels are very hard to compile (scipy contains c, fortran and assembly code, and must be compiled to mac, linux and windows). Providing a build env for that would make it prohibitively complicated and expensive, and basically would mirror github CI. That's the reason continuum is making money: they sell a python package distribution channel that is checked and locked.
lalaland1125 4y ago
A simple warning when a library adds a binary blob should be enough. You don't need to ban them entirely.

stingraycharles 4y ago

I don’t think this would work well for shipping packages that use proprietary libraries. But at the very least they could be flagged, yes.

meltyness 4y ago

Are they to test this condition for each input to each program?

kortex 4y ago

Self-loading code is a huge part of the value-add of python libraries. Many of the popular libraries (e.g. Numpy and friends) trigger a bewildering chain of events to compile from source if not installing from pre-built wheels. And if you do have wheels, you have opaque binary blobs. So pick your poison: compile-on-install with possible backdoor or prebuilt .so/.dylib/.pyc with possible backdoor. The most obvious (but not necessarily easiest) approach is to phase out setup.py and move everything to the declarative pyproject.toml approach. This is not just better for metadata (setup scripts make it really hard to statically infer what deps a lib has), it also allows for better control over what installers/toolchains run on install. Attackers still have quite a lot of latitude during the build phase, but at least libraries have the option to specify declaratively what permissions they need (and presumably the user has the option to forbid them). Also eval/exec are terrible and I wish there were a mode to disable their usage, but I don't know if the python runtime has some deep dependency on it. Maybe there's a way to restrict it so that only low level frames can call the eval opcode.

beardog 4y ago
>Also eval/exec are terrible and I wish there were a mode to disable their usage, You can use audit hooks in the sys module (as long as you load it first) to disable eval/exec/process spawning or even arbitrary imports or network requests.
fn-mote 4y ago
Would it be possible that the wheels could be built in a more-trusted / hardened environment? Having a binary blob isn't as serious when it comes from a trusted source. Almost all Debian/etc linux distributions have this feature (binary-downloading package manager). The hardening could mitigate on-compilation hacking. Obviously, this leaves "compile in the backdoor and wait for the user to fall into it" but at least this isn't an issue of compiling on the user's computer and it isn't a issue of binary blobs. And possibly there's a greater chance of detection if actual source code has to be available to compile.

woodruffw 4y ago

The short answer is that this can’t be easily mitigated at the package index level, at least not without massive breaking chances to the Python packaging ecosystem: PyPI would have to ban all setup.py based source distributions. Even then, that only pushes the problem down a layer: you’re still fundamentally installing third party code, which can do whatever it pleases. The problem then becomes one of static analysis, for which precision is the major limitation (in effect, just continuing the cat-and-mouse game.)

BiteCode_dev 4y ago

You can pip install complex stand alone executables, such as nodejs, and it's used in the entire ecosystem. In fact, most packages are now wheels, which are not sources: they are compressed, and may contain binaries for compiles extensions, something extremely popular (the scientific and AI stacks exist only because of this). Some packages need to be compiled after the fact, something that setup.py will trigger, and some even embed a fallback compiler, like some cython based packages. Also, remember there is very few people working on pypi, there is no moderation, anybody can publish anything, so you would need a bullet proof automated heuristic. That's either impractical, or too expensive. If you want a secure package distribution platform, there are commercial ones, such as anaconda. You get what you pay for.

ThePowerOfFuet 4y ago
I guess we're finding out the other side of that blade, huh?

weakfortress 4y ago

Even simpler solution: Require cryptographic signatures of the developers of projects along with hash-verified downloads via pip. The problem is a failure to understand security.

Blackthorn 4y ago
Requiring anything from open source authors is a losing proposition. Items of interest just won't end up on pypi. Iirc this chain of events already happened on another distribution platform.
anakaine 4y ago
A malicious author could embed malicious code in the package and still get the package signed. Hashing won't prevent this sort of thing on PyPi, it just addresses in transit and alternate supplier attacks.

ashishbijlani 4y ago

I’ve been building Packj [1] to flag PyPI/NPM/Ruby packages that contain suspicious decode+exec and other “risky” APIs using static analysis. It also uses strace-based dynamic analysis to monitor install-time filesystem/network activities. We have detected a bunch of malware with the tool. 1. https://github.com/ossillate-inc/packj https://github.com/ossillate-inc/packj flags malicious/risky packages.

_8j50 4y ago

Why would you think that would change a thing? Also, obfuscation has legitimate uses by people making stuff they don't want easily reversed. This isn't a python specific problem.

anony23 4y ago

They can just load the real payload as a second stage.