4 ms·

Where are you going to hide your monkey patching though? As long as your code is public, stuff like this is always going to stand out, because no one writes wei

Where are you going to hide your monkey patching though? As long as your code is public, stuff like this is always going to stand out, because no one writes weird magic one liners in python.

sunshowers 3y ago
I'm not a security-oriented professional, but to me a place I could hide this logic is by secretly evaling the contents of some file (like the "corrupt archive" used in xz) somewhere in the build process, hiding it behind a decorator or similar.
- echoangle 3y ago
  I’m not a security professional either, but that doesn’t sound very plausible to me. If you assume a maintainer who checks every commit added to the codebase, he’s hopefully blocking you the second he sees an eval call in your build script. And even a code audit should find weird stuff like that, if the code is pythonic and simple to read. And if it’s not, it should not be trusted and should be treated as malicious.
  - sunshowers 3y ago
    Well, the threat model here is that a maintainer themselves is the saboteur.
    - cjbprime 3y ago
      That was true for this project, which was almost orphaned to begin with. We'll run out of nearly-unmaintained critical infrastructure projects sometime. Larger projects with healthier maintenance situations are also at risk, and it's worth reasoning about how a group of honest developers could discover the actions of one malicious developer (with perhaps a malicious reviewer involved too).
- lijok 3y ago
  Would stick out like a sore thumb
cyanydeez 3y ago
This code was essentially monkey patched from a test script. Python automatically runs any code in a imported module, so not hard to see a chain of module imports that progressively modifies and deploys a similar structure.
zmmmmm 3y ago
The way python's run time literally executes code when you import a module makes it seem pretty easy to taint things from afar. You only need to control a single import anywhere in the dependency hierarchy and you can reach over and override any code somewhere else.
- sunshowers 3y ago
  Oh yeah, that's a fantastic point.
- eru 3y ago
  There are lints that will warn you, if your imported module does anything apart from define functions and classes. (Though not sure how fool-proof these are.)
DrFalkyn 3y ago
eval() is a big security hole

Where are you going to hide your monkey patching though? As long as your code is public, stuff like this is always going to stand out, because no one writes weird magic one liners in python.

sunshowers 3y ago

I'm not a security-oriented professional, but to me a place I could hide this logic is by secretly evaling the contents of some file (like the "corrupt archive" used in xz) somewhere in the build process, hiding it behind a decorator or similar.

echoangle 3y ago
I’m not a security professional either, but that doesn’t sound very plausible to me. If you assume a maintainer who checks every commit added to the codebase, he’s hopefully blocking you the second he sees an eval call in your build script. And even a code audit should find weird stuff like that, if the code is pythonic and simple to read. And if it’s not, it should not be trusted and should be treated as malicious.
- sunshowers 3y ago
  Well, the threat model here is that a maintainer themselves is the saboteur.
  - cjbprime 3y ago
    That was true for this project, which was almost orphaned to begin with. We'll run out of nearly-unmaintained critical infrastructure projects sometime. Larger projects with healthier maintenance situations are also at risk, and it's worth reasoning about how a group of honest developers could discover the actions of one malicious developer (with perhaps a malicious reviewer involved too).
lijok 3y ago
Would stick out like a sore thumb

cyanydeez 3y ago

This code was essentially monkey patched from a test script. Python automatically runs any code in a imported module, so not hard to see a chain of module imports that progressively modifies and deploys a similar structure.

zmmmmm 3y ago

The way python's run time literally executes code when you import a module makes it seem pretty easy to taint things from afar. You only need to control a single import anywhere in the dependency hierarchy and you can reach over and override any code somewhere else.

sunshowers 3y ago
Oh yeah, that's a fantastic point.
eru 3y ago
There are lints that will warn you, if your imported module does anything apart from define functions and classes. (Though not sure how fool-proof these are.)

DrFalkyn 3y ago

eval() is a big security hole