benjaminp / six

Python 2 and 3 compatibility library
https://six.readthedocs.io/
MIT License
987 stars 274 forks source link

Getting Code Vulnerability in "six.py" module file #380

Open racswebdev opened 10 months ago

racswebdev commented 10 months ago

Hello, I am getting code vulnerability when i am using this library, mainly in these lines - (mainly i am working with pyawscron and dynamodb-json module and which are installing this module)

Title = CWE-77,78,88 - OS command injection Detector name = OS command injection Vulnerable line = Line ( #735) - exec("""exec code in globs, locs""")
and the similar lines in different part of the code.

I am not sure how exactly i can fix it, also my second requirement is as now i am mostly dealing with python3 related codes from long time and now i didn't require python2 related things, but i am also not sure if some application under the hood are using python2, i need to veriy that. I am here to ask, if there is a security fix for this or there is any custom solution ? please let me know how can i deal with my applications as i am getting code vulnerability issues ?

Thanks

JakobDev commented 10 months ago

That is not a vulnerability

racswebdev commented 10 months ago

I am getting this vulnerability in AWS Inspector console on that particular line, if you have any suggestions or any replacement module which i can installed in place of pyawscron and dynamodb-json, as these 2 modules are installing the six module related files and folder ? Thanks

JakobDev commented 10 months ago

You could just ignore the error

racswebdev commented 10 months ago

This is related to organization code, if it would have been related to my personal project, i could have ignored that for sure, but as this is at organization level, i need to work on some fix, but i am confused as this is module related, how can i fix this ?

JakobDev commented 10 months ago

Did you have no way to add a exception? The code is just a wrapper to use the exec function in Python 2 and 3. As long as nobody calls this function, this is not a problem.

racswebdev commented 10 months ago

Ok, If i go ahead and comment that line in file (installed after installing pyawscron and dynamodb-json modules) where i am getting vulnerability - exec("""exec code in globs, locs"""), at first place, we usually think that if we will touch anything in 3rd party packages, it might break something else in the code but as this one is the simplest statement which is similar to print statement, we can ignore that.

Resolution as per me - I think that after installing these 2 modules (pyawscron and dynamodb-json), i can comment this vulnerable line in both the modules and then can create a zip folder to be uploaded as an AWS Lambda Layer, and then we would not be getting this vulnerability in whichever functionality we are using that AWS Lambda Layer.

Let me know if this is an correct resolution ? Please correct me if wrong and if you can add something that would be great.

Thanks for your suggestions, i really appreciate that.

racswebdev commented 9 months ago

Let me know your suggestions on my assumption discussed above ? Thanks

JakobDev commented 9 months ago

I never used WAS, so if it works for you, you can do it.

racswebdev commented 7 months ago

I am using AWS Cloud and AWS Inspector is showing this line - exec("""exec code in globs, locs""") as a vulnerable line. As we are using pyawscron and dynamodb-json modules, this six module is by default getting installed. As we are using this in our project, we need to fix this vulnerability. Still, I didn't have any clue about this as I cannot ignore this, what options do I have now to deal with this vulnerability? We can't touch the 3rd party files as it can break something other in the code, but now the question is what options we have, I have also searched the alternative modules but I didn't find anything. Please have WORKAROUND or something which I can try and resolve this.

racswebdev commented 7 months ago

Hello, Please share some updates on this. It would be really helpful. Thanks

Poikilos commented 6 months ago

The official repo here is likely not to remove a feature that makes things compatible since making things compatible is its purpose. It is the responsibility of the caller to not use exec insecurely, and six is merely a go-between between the caller and exec.

Therefore, if the library is being installed automatically by those packages,\ you must fork it to get the result you want:

  1. Fork this repo
  2. Comment out exec (probably keep the six implementation of it but replace the call to the real exec with raise NotImplementedError("exec is disabled for security") to make 100% sure things don't try to use it and then have mysterious errors due to not doing something they thought they did, which would be worse than the exception occurring. Regardless, you don't want your codebase to call it, so the exception will ensure that.)
  3. Make sure the setup metadata (or script) installs your forked version of six first (before any things that depend on it), so that installing your dependencies doesn't pull the official version. Examples (use the URL and branch of your repo, not this one, of course):

You may need to forcibly uninstall the official six using your install script since you will want your forked version to always be installed. If no solutions in links above work, you may have to script it: pip install --force-reinstall git+https://github.com/user/pyckagexyz.git@master or something like that.

For maintaining your fork well I suggest putting your change in another branch and using that branch after the @ sign or where main or master or another branch or commit is mentioned in any of these instructions. That way, you can always go to GitHub, your repo, then click "sync". Then make a pull request to yourself from your master to your branch. If it cannot be merged automatically, or if you want to skip the pull request step entirely, just delete the branch and remake it with the same name, and re-add your changes. Then your scripts will continue to be able to install the fork from that branch name. It will from then on be your responsibility to update it using these steps any time there are improvements on the official version that you need, which is likely not often though.