oiweiwei
feat: add fragmented bind/alter-context auth support
-
add fragmented bind/alter-context support for auth trailers exceeding max negotiated size. (see: https://pubs.opengroup.org/onlinepubs/9629399/chap12.htm)
-
add boundary checks for packet encoding.
See: https://github.com/oiweiwei/go-msrpc/issues/82
It still panics, but now pkt.start and pkt.end are both positive and in a reasonable range.
https://github.com/oiweiwei/go-msrpc/blob/4a46d4643f54f07b6e26a901d9d73b72233391d8/dcerpc/packet.go#L411
I'm sorry that I cannot provide you with an AP_REQ but maybe you can try patching Security.Init to return a ~6k buffer to test whether it still panics.
@rtpt-erikgeiser tried with zero-pad. it seems like Microsoft doesn't support v5.1 sort of things. hence, added auto-adjustable bind size, please check if it works for you.
also, you can control the size of the fragment manually (see WithFragmentSize option)
No it panics with [0:6123] for a slice of capacity 4096. Do I need to use WithFragmentSize? I think it is good to have the option to set it, but usually the consumer of go-msrcp does not know that a larger fragment size will be required.
@rtpt-erikgeiser i've updated and checked end-to-end with auth-pad. it seems to be working for bind when we send more data than we set in max-xmit-frag. could you please double-check on your side.
With the latest commit, it does not panic anymore, but I get bind: invalid checksum. I think such a large Kerberos ticket may be reproducible by adding the user to a large number of groups.
@rtpt-erikgeiser thanks for the hint, will try to reproduce. i'm wondering if this is related to the issue: https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/kerberos-authentication-problems-if-user-belongs-to-groups (here it is said that maximum buffer for the ap request should be adjusted).