Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NetShareEnumAll raises UnexpectedStatusCode 'STATUS_BUFFER_OVERFLOW' when result is bigger than 1024 bytes #141

Open
14mRh4X0r opened this issue Sep 4, 2018 · 3 comments
Labels
bug DCERPC DCERPC related

Comments

@14mRh4X0r
Copy link

When NetShareEnumAll results (through RubySMB::Client#net_share_enum_all) are more than Ioctl's max_output_response bytes long (1024 by default), at least RubySMB::SMB2::Dcerpc#request raises a RubySMB::Error::UnexpectedStatusCode with the message 'STATUS_BUFFER_OVERFLOW'.

Additionally, when changing Dcerpc#net_share_enum_all to call request with max_recv_frag from BindAck as the max_output_response value (i.e. mimicking smbclient), the SMB2Header gets reset to defaults, causing the remote server to abort the connection.

This is the output of smbclient -L:

	Sharename       Type      Comment
	---------       ----      -------
	ADMIN$          Disk      Remote Admin
	C$              Disk      Default share
	D$              Disk      Default share
	E$              Disk      Default share
	H$              Disk      Default share
	IPC$            IPC       Remote IPC
	K$              Disk      Default share
	K3              Disk      
	M$              Disk      Default share
	NETLOGON        Disk      Logon server share 
	P               Disk      
	P$              Disk      Default share
	print$          Disk      Printer Drivers
	S$              Disk      Default share
	Series Mirror   Disk      
	Series_Mirror   Disk      
	Share           Disk      
	SYSVOL          Disk      Logon server share 
	T$              Disk      Default share
@busterb
Copy link
Contributor

busterb commented Mar 12, 2019

Hmm, so we need to advertise a bigger buffer in the request?

@14mRh4X0r
Copy link
Author

I think that's a workaround rather than a solution.
From what I gather, STATUS_BUFFER_OVERFLOW is not an error as much as an indication that it has more data than we advertised we could handle; the server I tested against happily returned the first 1024 bytes of the DCERPC data. There is probably a way to request the rest of the data.

@14mRh4X0r
Copy link
Author

After reading the spec, yes, we should advertise a bigger buffer. Preferably the size returned by the server in the bind ack, if it's not too large.

@cdelafuente-r7 cdelafuente-r7 added bug DCERPC DCERPC related labels Sep 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug DCERPC DCERPC related
Projects
None yet
Development

No branches or pull requests

3 participants