-
Notifications
You must be signed in to change notification settings - Fork 8k
Move .NET method invocation logging to after the needed type conversion is done for method arguments #25022
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
Conversation
src/System.Management.Automation/engine/runtime/Binding/Binders.cs
Outdated
Show resolved
Hide resolved
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
Does this address the perf issues with amsi logging? #24459 for example, theres a few others |
|
@SeeminglyScience and @TravisEz13 The comment #25022 (review) was addressed. The PR is ready for another pass of review from both of you. Thanks! |
src/System.Management.Automation/engine/runtime/Binding/Binders.cs
Outdated
Show resolved
Hide resolved
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.
LGTM with one optional suggestion
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.
LGTM!
|
/backport to release/v7.4 |
|
📣 Hey @daxian-dbw, how did we do? We would love to hear your feedback with the link below! 🗣️ 🔗 https://aka.ms/PSRepoFeedback |
|
/backport to release/v7.5 |
|
Started backporting to release/v7.4: https://github.com/PowerShell/PowerShell/actions/runs/13931074040
|
|
@daxian-dbw backporting to "release/v7.4" failed, the patch most likely resulted in conflicts: $ git am --3way --empty=keep --ignore-whitespace --keep-non-patch changes.patch
Applying: Make sure the arguments used with .NET method logging are after the needed type conversion
Using index info to reconstruct a base tree...
M src/System.Management.Automation/engine/runtime/Binding/Binders.cs
Falling back to patching base and 3-way merge...
Auto-merging src/System.Management.Automation/engine/runtime/Binding/Binders.cs
CONFLICT (content): Merge conflict in src/System.Management.Automation/engine/runtime/Binding/Binders.cs
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
Patch failed at 0001 Make sure the arguments used with .NET method logging are after the needed type conversion
Error: The process '/usr/bin/git' failed with exit code 128Please backport manually! |
|
Started backporting to release/v7.5: https://github.com/PowerShell/PowerShell/actions/runs/13931076169
|
|
@daxian-dbw backporting to "release/v7.5" failed, the patch most likely resulted in conflicts: $ git am --3way --empty=keep --ignore-whitespace --keep-non-patch changes.patch
Applying: Make sure the arguments used with .NET method logging are after the needed type conversion
Using index info to reconstruct a base tree...
M src/System.Management.Automation/engine/runtime/Binding/Binders.cs
Falling back to patching base and 3-way merge...
Auto-merging src/System.Management.Automation/engine/runtime/Binding/Binders.cs
CONFLICT (content): Merge conflict in src/System.Management.Automation/engine/runtime/Binding/Binders.cs
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
Patch failed at 0001 Make sure the arguments used with .NET method logging are after the needed type conversion
Error: The process '/usr/bin/git' failed with exit code 128Please backport manually! |
|
@PowerShell/powershell-maintainers triage decision - More time in the 7.5 release before considering for 7.4 |
PR Summary
This PR is to fix a MSRC report about a bug in the .NET method logging implementation. The report is not considered a vulnerability, so I'm submitting the fix in GitHub.
The .NET method invocation logging is currently called before PowerShell does any of the needed type conversion for the method arguments, and it results in inaccurate information being logged to AMSI.
The fix is to move .NET method invocation logging to after the needed type conversion is done for method arguments.
The following is the comparison between before and after the fix when turning on the console logging for the AMSI notification feature:
Before the fix -- it logs
.GetType(<Foo>)After the fix -- it logs
.GetType(<System.Management.Automation.AmsiUtils>)PR Context
PowerShell 7.3 added a new feature that will log any .NET method calls and provide it to the IAntimalwareProvider2.Notify call. As an example running the following will result in the string below being provided to the AMSI provider to check before running
This allows antimalware providers registered with AMSI to be able to detect the runtime values provided to .NET methods even if they are obfuscated in the code and missed by any static analysis of the scriptblock text being run.
A bug in the implementation means that the provided args in the LogMemberInvocation method that builds the string to provide to AMSI are the ones before they are casted when actually invoking them.
For any .NET method that accepts a string we can now provide a custom class with a
ToStringmethod that returns the value we want to provide to the .NET call but the AMSI notify string value will just be the class name. With this we can now bypass the checks that may be in place to stop things like the below which would typically be picked up by AMSI due to the presence of the keywordAmsiUtilsin the string.Repro Steps
Run the following PowerShell script
The type name string provided at runtime to
GetTypeisSystem.Management.Automation.AmsiUtilsbut AMSI will see the following in the member invocation log, masking the true intention of the call.