-
Notifications
You must be signed in to change notification settings - Fork 3
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
csv-lint & json-lint: Use printf %q
to sanatize input and avoid command injection
#196
Conversation
@@ -40,6 +40,7 @@ jobs: | |||
run: | | |||
cd csvlint | |||
for file in ${{ steps.changed-files.outputs.all_changed_files }}; do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is 42 subject to injection?
Did you asses env
laundering as a potential mitigation? See the discussion in the "Remediation" section here:
https://securitylab.github.com/research/github-actions-untrusted-input/
env:
FILES: ${{ steps.changed-files.outputs.all_changed_files }}
run:
for file in $FILES; ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is 42 subject to injection?
I don't believe so. My understanding is that bash has a strict interpenetration of the input parameter for a for
loop. Similar to how command injection should not be possible with FOO=${{ steps.changed-files.outputs.all_changed_files }}
Related since we are discussing it, I considered also setting the IFS
to correctly handle filenames with spaces. But setting this value would actually make a theoretically command injection easier (though in theory not possible given the printf
change).
Let me know if you have any opinion on if I should make that change.
Did you asses env laundering as a potential mitigation?
As I understand it the printf
would still be necessary. Once the for
loop logic breaks apart the input I think injection may still be possible. Do you think it's worth adding this protection given the above? I have no concerns, just trying to keep complexity to a minimum.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@wadells friendly ping on this when you have a chance. Not high priority, but it would be nice to finish this NCC finding out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry -- you hadn't requested re-review, so this wasn't showing up in my review queue:
The best way to make sure I (or most other folks) revisit something (especially if I've requested changes) is to re-request review. Otherwise, if I get pulled away from the initial @ notification (for whatever reason), it'll never show back up in my queue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, requested. To be clear I have not made any changes yet, I am just looking for feedback on if we want to additionally add the environment filter.
printf %q
is a useful feature whenever we need to provide the input into a shell command. It will escape characters which could be used for injection.This PR fixes https://github.com/gravitational/security-findings/issues/52