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

ruby dangerous-exec rule did not report dangerous usages properly #3396

Open
1 task
JazJas opened this issue Jun 7, 2024 · 0 comments
Open
1 task

ruby dangerous-exec rule did not report dangerous usages properly #3396

JazJas opened this issue Jun 7, 2024 · 0 comments
Labels
bug Something isn't working

Comments

@JazJas
Copy link

JazJas commented Jun 7, 2024

Describe the bug
The existing rule "semgrep-rules/blob/develop/ruby/lang/security/dangerous-exec.yaml" did not recognize dangerous usages properly. It could miss dangerous usage, and also incorrectly report a proper usage as dangerous.

To Reproduce
The sample code containing both dangerous and secure 'system' command usages (in total four cases) is given below:
1 class T
2 def initialize(inputs)
3 @input = inputs[1]
4 # Case 1, vulnerable usage of system command, reported, expected but don't believe this is because the dangerous syntax is correctly recognised.
5 system "echo #{@input}"
6 # Case 2, secure usage of system command, reported, unexpected
7 system "echo", @input
8 end
9 def process
10 # Case 3, vulnerable usage of system command, but not reported, unexpected
11 system "echo #{@input}"
12 # Case 4, secure usage of system command, not reported, although expected, but don't believe this is because the secure syntax is correctly recognised.
13 system "echo", @input
14 end
15 end
16
17 # Sample input with user-controlled data
18 inputs = ["input 1", "input 2; echo 'Malicious code executed'"]
19 p = T.new(inputs)
20 p.process

The output of running the script are:
$ ruby test.rb
input 2
Malicious code executed
input 2; echo 'Malicious code executed'
input 2
Malicious code executed
input 2; echo 'Malicious code executed'

These indicated that Case 1 and Case 3 are vulnerable to command injection. However, the scan results show that Case 1 and Case 2 are vulnerable to command injection:

$ semgrep --config "p/ruby" test.rb

┌─────────────┐
│ Scan Status │
└─────────────┘
Scanning 1 file (only git-tracked) with 65 Code rules:

CODE RULES
Scanning 1 file with 65 ruby rules.

SUPPLY CHAIN RULES

💎 Run semgrep ci to find dependency
vulnerabilities and advanced cross-file findings.

PROGRESS

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 0:00:00

┌─────────────────┐
│ 2 Code Findings │
└─────────────────┘

test.rb
❯❱ ruby.lang.security.dangerous-exec.dangerous-exec
      Detected non-static command inside system. Audit the input to 'system'. If unverified user data can
      reach this call site, this is a code injection vulnerability. A malicious actor can inject a
      malicious script to execute arbitrary code.
      Details: https://sg.run/R8GY

        5┆ system "echo #{@input}"
        ⋮┆----------------------------------------
        7┆ system "echo", @input

┌──────────────┐
│ Scan Summary │
└──────────────┘

Ran 65 rules on 1 file: 2 findings.

Expected behavior
The dangerous usages of 'system' command at Lines 5 and 11 should be reported. On the other hand, the secure usages at Lines 7 and 13 should NOT be reported.

Priority
How important is this to you?

  • P0: blocking me from making progress
    There is no proper option to choose.
    I chose P0 because this bug impacts the reputation of semgrep. Due to this issue, I lack confidence in trusting the output of this rule, and potentially other rules as well.

Additional Context
According to my observations, it seems the rule might be incorrectly affected by the scope/context of variables presented in the 'system' command.

@JazJas JazJas added the bug Something isn't working label Jun 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Development

No branches or pull requests

1 participant