Fix bug #7146 - Samba miss-parses authenticated RPC packets.

Parts of the Samba RPC client and server code misinterpret authenticated
packets.

DCE authenticated packets actually look like this :

+--------------------------+
|header                    |
| ... frag_len (packet len)|
| ... auth_len             |
+--------------------------+
|                          |
| Data payload             |
...                     ....
|                          |
+--------------------------+
|                          |
| auth_pad_len bytes       |
+--------------------------+
|                          |
| Auth footer              |
| auth_pad_len value       |
+--------------------------+
|                          |
| Auth payload             |
| (auth_len bytes long)    |
+--------------------------+

That's right. The pad bytes come *before* the footer specifying how many pad
bytes there are. In order to read this you must seek to the end of the packet
and subtract the auth_len (in the packet header) and the auth footer length (a
known value).

The client and server code gets this right (mostly) in 3.0.x -> 3.4.x so long
as the pad alignment is on an 8 byte boundary (there are some special cases in
the code for this).

Tridge discovered there are some (DRS replication) cases where on 64-bit
machines where the pad alignment is on a 16-byte boundary. This breaks the
existing S3 hand-optimized rpc code.

This patch removes all the special cases in client and server code, and allows
the pad alignment for generated packets to be specified by changing a constant
in include/local.h (this doesn't affect received packets, the new code always
handles them correctly whatever pad alignment is used).

This patch also works correctly with rpcclient using sign+seal from
the 3.4.x and 3.3.x builds (testing with 3.0.x and 3.2.x to follow)
so even as a server it should still work with older libsmbclient and
winbindd code.

Jeremy

0 files changed, 0 insertions, 0 deletions