[Samba] rpcclient netshareenum 502 causes SEGV

[pisymbol .]

Hello:

I have a Windows 2003 Server that is causing rpcclient to SEGV via the
following command:

$ rpcclient -U Administrator%foobar -c 'netshareenum 502' <server>
...
type: 0x6269: SEC_DESC_OWNER_DEFAULTED SEC_DESC_DACL_DEFAULTED
SEC_DESC_SACL_DEFAULTED SEC_DESC_DACL_TRUSTED
SEC_DESC_SACL_AUTO_INHERIT_REQ SEC_DESC_SACL_PROTECTED
SEC_DESC_RM_CONTROL_VALID
SACL
Segmentation fault (core dumped)

I did a little poking and it seems that the issue is here:

source3/rpcclient/cmd_srvsvc.c:
384     case
502:

385         for (i = 0; i <
totalentries;i++)

386
display_share_info_502(&info_ctr.ctr.ctr502->array[i]);
387         break;

Sorry for the formatting. But the NDR code yanks out 35 SHARE_INFO_502* *
entries* *but the array size NDR code calculates only 34. Since
"totalentries" is one entry too big, it causes rpcclient to go past the end
of the ctr502 array and SEGV.

See here:

(gdb) p *info_ctr.ctr.ctr502
$9 = {
  count = 34,
  array = 0x67a140
}
(gdb) p totalentries
$10 = 35

Commit history shows that when the specific enum shares got unionized this
loop changed to use "totalentries" intsead of "ctr.num_entries," which
without looking into it might have been equivalent to "count."

It would seem to me that "totalentries" really has to be bounds checked
here else you can fall into this trap.

I know this is ugly, but couldn't something be done like
offsetof(ctr.share.infoXX, count) to verify that that the array size and
total entries match. Or perhaps even better check this bounds condition
during the NDR pull out unmarshalling code? (that is what I would vote for
since it puts less of a burden on the callee but there may be cases where
knowing the total entries vs what is in the array is useful, not sure...).

I am by no means a Samba expert but any insight into this issue would be
greatly appreciated.

Cheers!

-aps