Use ntdll.dll rather than KERNEL32.dll to intercept windows library calls
#51
Conversation
SEC-279 Fuzzer Windows, use ntdll library rather than win32 to monitor functions
ntdll is lower level than win32 and is expected to be present in all windows systems. |
There was a problem hiding this comment.
Haven't tested on a windows machine yet but looks good from a code review.
As mentioned in a comment the only required change I would like to request would be around handling the windows unicode string handling to avoid security pitfalls and improve performance.
| - from the experimentations we get values such as: | ||
| - open file in read only: 0x80100080 | ||
| - open file in write only: 0x40100080 | ||
| - this matches other known windows constants that exist are: |
There was a problem hiding this comment.
Adding some references for the future:
https://learn.microsoft.com/en-us/windows/win32/secauthz/access-mask-format
https://referencesource.microsoft.com/#System.Runtime.Remoting/channels/ipc/win32namedpipes.cs,78
So makes sense that these values are in different from the supposed flag values.
| let unicode_data = (*obj_attr.ObjectName).Buffer; | ||
|
|
||
| // NOTE: `unicode.Length` gives the wrong size of the string | ||
| // Instead we manually calculate the size of the string by searching the first null byte |
There was a problem hiding this comment.
I think this approach is not ideal as it introduces possibly out of bound reads/overflows and does not take advantage of the idea of the UNICODE_STRING approach.
I think we should rely on nt-string crate to handle this conversion for us, as we will likely use this in multiple occasions when interacting with windows strings.
https://colinfinck.de/posts/nt-string-the-missing-windows-string-types-for-rust/ for reference
There was a problem hiding this comment.
Good advice 👍. I will look into it
Fix SEC-279