Rule for the use of the command: [ScriptBlock]::Create

[iRon7]

Summary of the new feature
Check for the use of the command: [ScriptBlock]::Create

And return a warning like:

[ScriptBlock]::Create is used. Please remove [ScriptBlock]::Create from script and find other options instead.

For the same reason as PSAvoidUsingInvokeExpression, [ScriptBlock]::Create should not be used as it fabricates a [ScriptBlock] based on input that either originates from somewhere the script author does not have control over or could be a hardcoded as an expression { ... } otherwise.

See also:

• Running partly trusted PowerShell code in a restricted security environment.
  #12377
• PowerShell Security Best Practices with the video recorded and available here: https://channel9.msdn.com/Events/Blue-Hat-Security-Briefings/BlueHat-Security-Briefings-Fall-2013-Sessions/PowerShell-Best-Practices.

What is the latest version of PSScriptAnalyzer at the point of writing
1.18.3

[bergmeister]

The InjectionHunter module already provides a set of custom PSSA rules for that.
Issue #989 is tracking its integration into the built in rules of PSSA. Therefore I am inclined to close this issue, what do you think?

[iRon7]

I agree, the only thing that worries me is that this Issue #989 is open for more then 2 years with hardly any activity. Creating a PSAvoidUsingScriptBlockCreate rule (based on the PSAvoidUsingInvokeExpression rule) is likely much easier to implement.
The purposed PSAvoidUsingScriptBlockCreate rule can simply follow the same life cycle as the PSAvoidUsingInvokeExpression rule, meaning remove/disable it when the Injection Hunter has been integrated into PSSA.

Anyways, I leave it up to you to close this issue (or not).

[bergmeister]

It is the nature of open source projects that many issues don't get picked up due to a lack of resourcing or prioritisation. If you want, feel free to create a PR just for that rule.

[bergmeister]

@iRon7 Do you plan to open a PR? If not, I am going to close in favour of the existing issue #989

[rjmholt]

Personally my preference would be to just enhance the Invoke-Expression rule; it's not well named, but I think the spirit of the rule is "avoid arbitrary script evaluation", which this is

[iRon7]

@bergmeister, sorry for my late reaction, I never did a formal PR before, I feel that I first need some more time to familiarize myself with the processes behind but I am to busy at the moment with some other projects.
In other words, I have closed the issue for now as I can always reopen it if I feel more confident and there is no progress with #989.

[iRon7]

Just an additional note:

Like Invoke-Expression and [ScriptBlock]::Create(), $ExecutionContext.InvokeCommand.ExpandString could also be exploit by malicious code injections, e.g.:

$Test = 'test $("test" | Set-Content .\test.txt) 123'
$ExecutionContext.InvokeCommand.ExpandString($Test)