Bug 9278 - ldap server didn't handle correctly sd_flags controls with control values on more than 4 bytes
ldap server didn't handle correctly sd_flags controls with control values on ...
Status: RESOLVED INVALID
Product: Samba 4.0
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB
4.0.0rc2
All All
: P5 normal
: ---
Assigned To: Simo Sorce
Samba QA Contact
:
Depends on:
Blocks: 9279
  Show dependency treegraph
 
Reported: 2012-10-10 06:53 UTC by Matthieu Patou
Modified: 2013-01-27 14:29 UTC (History)
1 user (show)

See Also:


Attachments
Keytab to decrypt the trace (545 bytes, application/octet-stream)
2012-10-10 06:53 UTC, Matthieu Patou
no flags Details
Trace from ldp (14.72 KB, application/octet-stream)
2012-10-10 07:01 UTC, Matthieu Patou
no flags Details
Screenshot of the packet description (283.88 KB, image/png)
2012-10-25 04:57 UTC, Matthieu Patou
no flags Details
New trace with kerberos and ldap packets (32.23 KB, application/octet-stream)
2012-10-25 04:58 UTC, Matthieu Patou
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthieu Patou 2012-10-10 06:53:50 UTC
Created attachment 8034 [details]
Keytab to decrypt the trace

ldp sends sd_flags control with a control value on 5 bytes, the control parser only reads 4 bytes and of course reads a completely bogus value.
As the specification says that it's on 4 bytes one of the options should be to reject the request if the integer is longer.
The other is only to parse the lower four bytes.
Comment 1 Matthieu Patou 2012-10-10 07:01:42 UTC
Created attachment 8035 [details]
Trace from ldp
Comment 2 Matthieu Patou 2012-10-10 07:14:22 UTC
On packet 34 we can see the request from ldp with more than 32 bit integer as the control value.
Comment 3 Stefan Metzmacher 2012-10-24 21:48:12 UTC
I think we should try to fix this before the release if possible
Comment 4 Matthieu Patou 2012-10-25 04:57:33 UTC
Created attachment 8107 [details]
Screenshot of the packet description
Comment 5 Matthieu Patou 2012-10-25 04:58:54 UTC
Created attachment 8108 [details]
New trace with kerberos and ldap packets
Comment 6 Simo Sorce 2012-10-25 06:20:24 UTC
Sorry Matthieu, but the control structure is fine according to spec and the Ldap server code looks correct and should decode it properly.
The value sent by ldp in this case is '4'

4 is: DACL_SECURITY_INFORMATION (DSI)
according to MS-ADTS: 3.1.1.3.4.1.11

From what I seem to read in the code what appears to be happening is that our code simply does not handle properly any case where flags are 0 or 0x0F

Any time windows sends us only one of the bits of info and not a whole SD we replace the whole SD with the partial info, corrupting the SD in the process.
(I am reading code at 2.20Am so take this with a grain of salt :-)
Comment 7 Simo Sorce 2012-10-25 06:22:10 UTC
And fo course 2 seconds after I hit 'enter' Matthieu correctly points me at descr_handle_sd_flags() :-)
Comment 8 Matthieu Patou 2012-11-06 09:13:38 UTC
After talking to simo he proved me that this one is not a bug
Comment 9 Matthieu Patou 2012-11-06 09:15:06 UTC
After talking to simo he proved me that this one is not a bug as the ldap part is parsing the control correctly.

The problem is down the stack and I think the bug https://bugzilla.samba.org/show_bug.cgi?id=9279 is tracking it. I propose to close this bug and focus on 9279
Comment 10 Stefan Metzmacher 2012-11-12 08:35:53 UTC
The problem is different...

The server closes the connection (TCP FIN,ACK) after it is idle for 36 seconds.
See frame 88 in sd_corruption2.

In frame 93 the client sends the LDAP modify 1 minute and 21 seconds later
and gets (TCP,RST) from the server.

Where do you see a problem, here?

The idle timeout of 36 seconds is strange, our default is 900 seconds.
See ldapsrv_load_limits(), do you have configured MaxConnIdleTime?
Comment 11 Stefan Metzmacher 2012-11-12 09:51:04 UTC
Matthieu, could you reproduce it with a capture(keytab) and a level 10 log file and an ldbsearch --show-binary ldif before and after the change?
Comment 12 Stefan Metzmacher 2012-11-12 10:05:25 UTC
(In reply to comment #11)
> Matthieu, could you reproduce it with a capture(keytab) and a level 10 log file
> and an ldbsearch --show-binary ldif before and after the change?

Please also include the ldif with base64 output.