A Large-Scale Security-Oriented Static Analysis of Python Packages in PyPI
1–10 of 28 posts
Re: A Large-Scale Security-Oriented Static Analysis of Python Packages in PyPI
#2Their conclusion, "security issues are common in PyPI packages", doesn't really follow from the results. Their methods will classify any use of a function that is not cryptographically secure (MD5, random), even if it is not used in a cryptographic setting. Similarly any use of a function that is not safe to use on untrusted input (pickle, yaml.load, subprocess, eval) will be flagged, even if the usage is completely safe.
Re: A Large-Scale Security-Oriented Static Analysis of Python Packages in PyPI
#3Their conclusion, "security issues are common in PyPI packages", doesn't really follow from the results. Their methods will classify any use of a function that is not cryptographically secure (MD5, random), even if it is not used in a cryptographic setting. Similarly any use of a function that is not safe to use on untrusted input (pickle, yaml.load, subprocess, eval) will be flagged, even if the usage is completely…
Yes this, but also you shouldn't do an analysis like this on all of PyPi. Anyone can upload to it. It's full of abandoned experiments, name-squatting, and college students uploading hello world libraries just to learn how to do it. Analyzing those is pointless because nobody is using them and nobody is going to use them.
Also listing the subprocess module as a standout because of code injection seems silly. That's the entire point of it existing. You may as well say a shell is insecure because it allows injecting shell commands. Obviously, don't put strings from untrusted sources in there, but Python is largely intended for system administration automation, the first thing to turn to when the shell isn't enough if you don't like Perl. It would be pretty useless if you couldn't actually use it to orchestrate arbitrary shell commands.
Re: A Large-Scale Security-Oriented Static Analysis of Python Packages in PyPI
#4From the PDF, these are some of the security vulnerabilities that the static analysis came up with:
Use of the exec function
Insecure permissions for files
Binding a socket to all network interfaces
Use of hard-coded passwords in non-function contexts
Use of hard-coded passwords in function arguments
Use of hard-coded passwords in default function arguments
Use of hard-coded temporary directories
Using pass as a catch-all-style exception handling
Using continue as a catch-all-style exception handling
Running a Flask web application in debug mode
Use of insecure deserialization
Use of insecure deserialization
Use of MD2, MD4, MDS, or SHA1 hash functions
Use of insecure ciphers such as DES
Use of insecure cipher modes
Use of the insecure mkt emp function
Use of the possibly insecure eval function
Use of the possibly insecure mark_safe function
Use of the insecure HTTPSConnection with some Python versions
Use of a file scheme in urlopen with some Python versions
Use of pseudo-random generators for cryptography/security tasks
Use of the insecure Telnet protocol
Use of possibly insecure Extensible Markup Language (XML) parsing
Most of those can be used securely (e.g. the mark_safe() function is specifically intended for context where the user understands what they are doing - some people may mess it up, but its presence does not indicate a security vulnerability). So the "at least one issue is present for about 46% of the Python packages" number doesn't worry me too much.
Re: A Large-Scale Security-Oriented Static Analysis of Python Packages in PyPI
#5From the PDF, these are some of the security vulnerabilities that the static analysis came up with: Use of the exec function Insecure permissions for files Binding a socket to all network interfaces Use of hard-coded passwords in non-function contexts Use of hard-coded passwords in function arguments Use of hard-coded passwords in default function arguments Use of hard-coded temporary directories Using pass as a catc…
s/can/will most likely/. The typical python programmer has a whistle and readily available graveyard. :-)
Re: A Large-Scale Security-Oriented Static Analysis of Python Packages in PyPI
#6Their conclusion, "security issues are common in PyPI packages", doesn't really follow from the results. Their methods will classify any use of a function that is not cryptographically secure (MD5, random), even if it is not used in a cryptographic setting. Similarly any use of a function that is not safe to use on untrusted input (pickle, yaml.load, subprocess, eval) will be flagged, even if the usage is completely…
Yes this, but also you shouldn't do an analysis like this on all of PyPi. Anyone can upload to it. It's full of abandoned experiments, name-squatting, and college students uploading hello world libraries just to learn how to do it. Analyzing those is pointless because nobody is using them and nobody is going to use them. Also listing the subprocess module as a standout because of code injection seems silly. That's th…
I was with you until you said that Python is largely intended for system administration automation.
Python is used in a wide variety of application environments, especially the web. For example, early versions of Youtube were nothing more than a Python application. Many websites run Django, or other web frameworks. Python is heavily used in scientific computing environments, in data retrieval and visualization, as well as fintech (ie hedge funds).
Its use in system administration/configuration management is real and significant, but represents a smallish proportion of its use.
Certainly some static analysis would be beneficial here, especially in areas like science or financial technology, but much of your original point remains completely true- much of concern raised speaks more to system design around passing strings as objects of reference, and security design, rather than language issues.
Re: A Large-Scale Security-Oriented Static Analysis of Python Packages in PyPI
#7From the PDF, these are some of the security vulnerabilities that the static analysis came up with: Use of the exec function Insecure permissions for files Binding a socket to all network interfaces Use of hard-coded passwords in non-function contexts Use of hard-coded passwords in function arguments Use of hard-coded passwords in default function arguments Use of hard-coded temporary directories Using pass as a catc…
why is mktemp insecure?
Re: A Large-Scale Security-Oriented Static Analysis of Python Packages in PyPI
#8From the PDF, these are some of the security vulnerabilities that the static analysis came up with: Use of the exec function Insecure permissions for files Binding a socket to all network interfaces Use of hard-coded passwords in non-function contexts Use of hard-coded passwords in function arguments Use of hard-coded passwords in default function arguments Use of hard-coded temporary directories Using pass as a catc…
why is mktemp insecure?
Python mktemp has been deprecated since 2003. I there’s a race condition that allows a malicious process to slip in a file or symlink with different permissions at the path mktemp returns.
Re: A Large-Scale Security-Oriented Static Analysis of Python Packages in PyPI
#9Earlier quoted context omitted.
Yes this, but also you shouldn't do an analysis like this on all of PyPi. Anyone can upload to it. It's full of abandoned experiments, name-squatting, and college students uploading hello world libraries just to learn how to do it. Analyzing those is pointless because nobody is using them and nobody is going to use them. Also listing the subprocess module as a standout because of code injection seems silly. That's th…
I was with you until you said that Python is largely intended for system administration automation. Python is used in a wide variety of application environments, especially the web. For example, early versions of Youtube were nothing more than a Python application. Many websites run Django, or other web frameworks. Python is heavily used in scientific computing environments, in data retrieval and visualization, as we…
Instagram still runs on Python as well, I believe.
Re: A Large-Scale Security-Oriented Static Analysis of Python Packages in PyPI
#10Their conclusion, "security issues are common in PyPI packages", doesn't really follow from the results. Their methods will classify any use of a function that is not cryptographically secure (MD5, random), even if it is not used in a cryptographic setting. Similarly any use of a function that is not safe to use on untrusted input (pickle, yaml.load, subprocess, eval) will be flagged, even if the usage is completely…
Yes this, but also you shouldn't do an analysis like this on all of PyPi. Anyone can upload to it. It's full of abandoned experiments, name-squatting, and college students uploading hello world libraries just to learn how to do it. Analyzing those is pointless because nobody is using them and nobody is going to use them. Also listing the subprocess module as a standout because of code injection seems silly. That's th…
[deleted]