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

Remove paramiko invoke_shell and fix example #377

Merged
merged 2 commits into from Dec 10, 2018
Merged

Remove paramiko invoke_shell and fix example #377

merged 2 commits into from Dec 10, 2018

Conversation

ericwb
Copy link
Member

@ericwb ericwb commented Aug 27, 2018

Paramiko's invoke_shell function does not take a command argument
even though the Bandit example implied that. It simply opens a stream
for communicating with a shell. Therefore, it should not be flagged
as part of the Bandit scan.

The current example of paramiko command injection does not properly
create an instance of the SSHClient before calling the functions
on the client. Instead it's calling the functions statically which
is not proper syntax.

This patches updates the plugin and example. Bandit, however, is
still functioning properly to detect the improper use of exec_command().

Fixes Issue #375

Signed-off-by: Eric Brown browne@vmware.com


# this is not safe
SSHClient.invoke_shell('something; bad; here\n')

client.invoke_shell('something; bad; here\n')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is an interactive session and doesn't need an argument. But doesn't really matter for the test.

http://docs.paramiko.org/en/2.4/api/client.html#paramiko.client.SSHClient.invoke_shell

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch. invoke_shell should have never been part of the check. I'll update the example and the plugin

Paramiko's invoke_shell function does not take a command argument
even though the Bandit example implied that. It simply opens a stream
for communicating with a shell. Therefore, it should not be flagged
as part of the Bandit scan.

The current example of paramiko command injection does not properly
create an instance of the SSHClient before calling the functions
on the client. Instead it's calling the functions statically which
is not proper syntax.

This patches updates the plugin and example. Bandit, however, is
still functioning properly to detect the improper use of exec_command().

Fixes Issue #375

Signed-off-by: Eric Brown <browne@vmware.com>
@ericwb ericwb changed the title Correct the paramiko injection example Remove paramiko invoke_shell and fix example Aug 28, 2018
@mcandre
Copy link

mcandre commented Oct 12, 2018

Really, paramiko should be excluded from scanning. The whole point of paramiko is to be able to run arbitrary shell commands. How exactly is the programmer supposed to accomplish this without use of exec_command? Can you recommend a sanitizer for arbitrary shell commands? Would bandit recognize when an "approved" sanitizer is applied to the commands?

bandit should not bother marking something as invalid until it can recommend at least one valid replacement. Otherwise, it's just complaining "Don't do this" when in fact the programmer must do this.

@ericwb ericwb merged commit 82d67c7 into PyCQA:master Dec 10, 2018
@ericwb ericwb deleted the paramiko_example branch December 10, 2018 02:30
@alterEgo123
Copy link

@mcandre Did you overcome this behaviour?

@ngie-eign
Copy link

Really, paramiko should be excluded from scanning. The whole point of paramiko is to be able to run arbitrary shell commands. How exactly is the programmer supposed to accomplish this without use of exec_command? Can you recommend a sanitizer for arbitrary shell commands? Would bandit recognize when an "approved" sanitizer is applied to the commands?

bandit should not bother marking something as invalid until it can recommend at least one valid replacement. Otherwise, it's just complaining "Don't do this" when in fact the programmer must do this.

I disagree with a caveat: yes, this is how paramiko is designed, but depending on what is passed in, one could get shell injection issues of some flavor (like shell=True with subprocess). B601 should be treated like a warning though and not an error, since it can’t really be worked around with the way the APIs are constructed today. I think this is worthy of an enhancement in bandit/paramiko, if the work isn’t too difficult to complete.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants