Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

B603 false positive? #333

Open
pzelnip opened this issue Jul 10, 2018 · 10 comments
Open

B603 false positive? #333

pzelnip opened this issue Jul 10, 2018 · 10 comments
Labels
bug Something isn't working
Milestone

Comments

@pzelnip
Copy link

pzelnip commented Jul 10, 2018

Describe the bug
I don't understand how I should "check for untrusted input.

To Reproduce
Steps to reproduce the behavior:

With the code:

import shlex
import subprocess

def foo():
    args = shlex.split("git rev-parse HEAD")
    return str(subprocess.check_output(args, shell=False), "utf-8").strip()

Gives Issue: [B603:subprocess_without_shell_equals_true] subprocess call - check for execution of untrusted input. I don't understand how this is shell equals true given that "shell=False" is passed, nor how this is untrusted input.

Expected behavior

This line shouldn't be flagged as a warning

Bandit version

bandit --version
bandit 1.4.0

Additional context

@bcaller
Copy link

bcaller commented Jul 11, 2018

B603 is subprocess_without_shell_equals_true... without. So it knows that shell=False.

However there can still be a problem: bandit is looking at subprocess.check_output(args, shell=False) and sees check_output with argument args.

Bandit doesn't know that args is safe. It just sees a variable which could have come from anywhere.

Unfortunately bandit isn't a code-flow analysis tool so it can't reason about what args is. It just flags a warning. You manually check the warning and decide to either add # nosec at the end of the line or
to turn off this B603 test if you find it unhelpful.

It's a false positive but the test is functioning as designed, as a simple linter to warn about possible issues.

@pzelnip
Copy link
Author

pzelnip commented Jul 11, 2018

I see your point, but I suppose I'm having trouble how you could possibly use subprocess.check_output without triggering B603. Ie I get that all it sees is args and it has no idea if args is trusted or not, but even if I put the string literal into the call:

return str(
        subprocess.check_output("git rev-parse HEAD".split(), shell=False), "utf-8"
    ).strip()

I still trigger B603. As such this feels more like "don't use subprocess.check_output" rather than "make sure the input to subprocess.check_output is trusted", so it feels like the description of B603 is misleading/not helpful. Or am I missing a way to use subprocess.check_output without triggering B603?

@bcaller
Copy link

bcaller commented Jul 11, 2018

Actually you're right. My apologies. I checked the code and the test is a bit dumb. It will flag any use of check_output regardless. The example in the test's docstring is subprocess.check_output(['/bin/ls', '-l']) which I wouldn't consider vulnerable to injection.

I agree with you that the test should be improved to decrease obvious false positives.

@Tatsinnit
Copy link

Tatsinnit commented Nov 9, 2018

+1 , also linking this to an another one: #373 . This happens with version 1.5.1 as well.

widdowquinn added a commit to widdowquinn/find_differential_primers that referenced this issue Feb 4, 2019
Bandit reports issues for "subprocess call- check for execution of
untrusted input", but in each case it's a false positive, as noted
here: PyCQA/bandit#333

The pdp_mafft_wrapper.py script catches STDOUT from MAFFT, and
cannot execute anything the user can't already run from the shell.
In addition, the command whose output is caught is sanitised before
it is used.

The test_*.py files have input that is declared in the function and
sanitised before use.
@ericwb ericwb added the bug Something isn't working label May 9, 2019
@ericwb ericwb added this to the Near Future milestone May 9, 2019
@amacfie
Copy link
Contributor

amacfie commented Jan 1, 2020

It would be easy to change the test to be like django_sql_injection.django_rawsql_used which doesn't generate an issue if the argument is a string literal.

Even then the confidence should not be high, which it is currently.

@Flauschbaellchen
Copy link

Is there a timeline when this bug will be fixed?
IMHO, the check would be very useful but the bug renders it completely useless and frustrating.

@SanketDG
Copy link

t would be easy to change the test to be like django_sql_injection.django_rawsql_used which doesn't generate an issue if the argument is a string literal.

How does this help here?

The best way seems to lower its confidence down to LOW, as there is no definite way of knowing that a input is truly secure.

fepitre added a commit to fepitre/apt-transport-in-toto that referenced this issue Dec 22, 2020
According to project PyCQA/bandit#333, the
bandit checker cannot be aware of trusted input defined from variable
which is in out case APT_METHOD_HTTP. We turn off the check for
this subprocess call.
fepitre added a commit to fepitre/apt-transport-in-toto that referenced this issue Jan 26, 2021
According to project PyCQA/bandit#333, the
bandit checker cannot be aware of trusted input defined from variable
which is in out case APT_METHOD_HTTP. We turn off the check for
this subprocess call.
fepitre added a commit to fepitre/apt-transport-in-toto that referenced this issue Jan 26, 2021
According to project PyCQA/bandit#333, the
bandit checker cannot be aware of trusted input defined from variable
which is in out case APT_METHOD_HTTP. We turn off the check for
this subprocess call.
@jackton1
Copy link

jackton1 commented May 25, 2021

+1 Waiting for the timeline on this issue also, Since it's not helpful to have to introduce # nosec each time for both B602 and B404

@BorjaEst
Copy link

BorjaEst commented Aug 7, 2023

Related to this issue, the reference https://bandit.readthedocs.io/en/1.7.5/plugins/b603_subprocess_without_shell_equals_true.html
says we should use shell=True and gives some references. However, when reading the references, those say the oposite, that we should avoid shell=True.
See for example:
https://security.openstack.org/guidelines/dg_use-subprocess-securely.html

If you use shell=True, your code is extremely likely to be vulnerable.

Isn't it a false false positive?

@nfantone
Copy link

This has been opened since 2018 — I suppose there's still no way to use check_output without triggering B603? And just FYI, the same is also true for B603 in Ruff.

barsilver pushed a commit to barsilver/secure-lambda-scanner that referenced this issue Jan 18, 2024
wenzeslaus added a commit to wenzeslaus/grass that referenced this issue Jun 15, 2024
The message 'check for execution of untrusted input' is triggered by any use of subprocess regardless of the actual input, so even fixed input triggers it. Bandit issue PyCQA/bandit#333 discusses that this is a common false positive triggered by any usage.

The pattern is common enough in our code to ignore this to avoid clutter and warning fatigue. We already ignore B404 mentioned in the issue above.
echoix pushed a commit to OSGeo/grass that referenced this issue Jun 16, 2024
The message 'check for execution of untrusted input' is triggered by any use of subprocess regardless of the actual input, so even fixed input triggers it. Bandit issue PyCQA/bandit#333 discusses that this is a common false positive triggered by any usage.

The pattern is common enough in our code to ignore this to avoid clutter and warning fatigue. We already ignore B404 mentioned in the issue above.
a0x8o pushed a commit to a0x8o/grass that referenced this issue Jun 17, 2024
The message 'check for execution of untrusted input' is triggered by any use of subprocess regardless of the actual input, so even fixed input triggers it. Bandit issue PyCQA/bandit#333 discusses that this is a common false positive triggered by any usage.

The pattern is common enough in our code to ignore this to avoid clutter and warning fatigue. We already ignore B404 mentioned in the issue above.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

10 participants