Fixed infinite loop when parsing dotnet TypeRef table #2045
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
There was a problem hiding this comment.
Please add bug fixes, new features, breaking changes and anything else you think is worthwhile mentioning to the master (unreleased) section of CHANGELOG.md. If no CHANGELOG update is needed add the following to the PR description: [x] No CHANGELOG update needed
CHANGELOG updated or no update needed, thanks! 😄
Hi @x9090 , thank you for the find and suggested fix - apologies for not getting back to you sooner! Please update the sample for testing and review the CLA requirements so we can move this PR forward. |
| @@ -370,6 +370,7 @@ def resolve_nested_typeref_name( | |||
| # If the ResolutionScope decodes to a typeRef type then it is nested | |||
| if isinstance(typeref.ResolutionScope.table, dnfile.mdtable.TypeRef): | |||
| typeref_name = [] | |||
| typeref_tb = [] | |||
There was a problem hiding this comment.
I'm not sure what _tb means, please add a comment or consider updating the name to something more obvious like _visited.
| typeref_name.append(name) | ||
| name = table_row.TypeName | ||
| table_row = get_dotnet_table_row(pe, dnfile.mdtable.TypeRef.number, table_row.ResolutionScope.row_index) | ||
| if table_row is None: | ||
| if table_row is None or table_row in typeref_tb: |
There was a problem hiding this comment.
We use similar logic in resolve_nested_typedef_name. What are your thoughts on also adding this check there?
|
@x9090 would you please sign the CLA so that we can merge this PR into capa? We'd love to get it in as part of the v7.1 release soon. |
|
friendly bump, @x9090 |
|
Without the CLA signed, we cannot merge this PR. I haven't been able to find the file shown in the screenshot on VT, so I can't reproduce this nor reimplement it. Perhaps we should close this PR until @x9090 returns? |
|
yes, let's wait for that or other people raising this issue |
Can we hunt for it on VT using a YARA rule? :) |
|
I did some VTGrep searches for the random looking strings in the screenshot and didn't come up with anything. Have you had any luck? |
|
I mean crafting a YARA for that specific behaviour mentioned. Possible? |
|
maybe by using the Yara .NET extension. It might be easier to manually craft a file by hand: just tweak two bytes (the table references). |
There was a
TypeReftable infinite loop issue when dotnet parser parsing a crafted dotnet sample with ref index refer to each other:Let me know if you need the sample for testing, I could upload it here.
Checklist