Samba 4.5.8 has been discovered to have a massively user impacting bug. Users who upgrade to 4.5.8 will be unable to manage their DNS regardless of whether they are using SAMBA_INTERNAL or BIND9_DLZ backends. The only possible fix at this time is to revert to 4.5.7. There is one associated CVE with the 4.5.8 release: CVE-2017-2619 DNS bug: https://bugzilla.samba.org/show_bug.cgi?id=12786 This has been reported across multiple OSes. It is impossible for users to provide additional information as the Samba bugzilla is broken and it is impossible to create new accounts. This is an urgent issue as it is highly visible to any users which use AD_DC; they will be completely unable to manage their DNS, which will cause widespread and pervasive impact to their environment.
Further testing has revealed that the bug may have been introduced somewhere in 4.5.7_2 or _3. Definitely could use some additional victims^Wvolunteers to test this issue. Multiple complete wipes of the OS and from-scratch domain creations result in the same exact error. This reproduced on i386, amd64, and aarch64 running 11.0-RELEASE-p9 and 12.0-CURRENT. However, my records very clearly document this as having worked on ALL of these architectures and releases with absolutely no problems using 4.5.7. Based on the samba.org bug records, this is impacting all OSes, so It's Not Just Us! Samba.org has a backpatch for 4.5.7 which addresses the mentioned vulnerability at https://download.samba.org/pub/samba/patches/samba-4.5.7-4.5.8.diffs.gz - manually applying these prior to the files/* patches did not break the build. I'm not sure what the right way to do this through the Makefile is though.
(In reply to Phillip R. Jaenke from comment #1) That's really weird and not good, but with the today's CVE I see no other option but upgrade Samba farther to 4.5.10 and so on... Can you please, provide the exact sequence and environment details that trig this bug, so others(and me) can reproduce it in their environments?
(In reply to Timur I. Bakeyev from comment #2) I absolutely concur; CVE-2017-7494's 'workaround' breaks AD functionality severely, and the impact is even worse. Nightmare scenario yet again. So pulling it up to 4.5.9+/4.6.3+ is the only option. My apologies, I completely forgot to include the reproduction. You'll need: 1-2x FreeBSD hosts, 1x Windows Server 2k8R2 or later host with RSAT FreeBSD: # samba-tool domain provision --adminpass=s00p3rs3cur3 --use-rfc2307 --dns-backend=BIND9_DLZ --host-name=TESTBSD --host-ip=10.10.0.10 --host-ip6=2001:470:AAAA::10 --function-level=2008_R2 --domain=TEST --realm=TEST.PVT (await domain creation) # samba-tool dns zonecreate 127.0.0.1 0.10.10.in-addr.arpa -U Administrator # samba-tool dns zonecreate 127.0.0.1 a.a.a.a.0.7.4.0.1.0.0.2.ip6.arpa -U Administrator OPTIONAL: add 'log level = 2 auth:10' in [global] section of /usr/local/etc/smb4.conf Windows: Install RSAT including DNS management Join domain TEST.PVT Reboot Open RSAT DNS tool and select the radio button to connect to 10.10.0.10 On the FreeBSD side you should see (this will be the only message): dcesrv_request: restrict auth_level_connect access to [dnsserver] with auth[type=0xa,level=0x2] on [ncacn_ip_tcp] from [ipv4:CLIENT.IP:PORT]
(In reply to Phillip R. Jaenke from comment #3) So, do I get it right, that just pushed 4.5.10/4.6.4 should be OK? I'll try to check myself, but you may judge quicker :)
I think it's best if we both test here. I was unable to get it working reliably again even when reverting to 4.5.7. Thankfully, the testing itself isn't very long.. it'll immediately tell you "access denied" for DNS management on the first attempt from RSAT. To avoid the domain join step, you can also use from any Windows 7/8/10/2k8/2k12 with RSAT installed: CMD C:\> RUNAS /NETONLY /USER:Administrator@REALM.NAME "mmc %SystemRoot%\system32\dnsmgmt.msc" I definitely would agree that instead of revert, the proper way to address the issue now is to perform all testing on 4.5.10+ and 4.6.4+ only.
Tested 4.5.10 - same problem. This appears to be a MAJOR regression in Samba somewhere. It's failing to configure for the specified IP address correctly, but OTHER IP addresses permit access. More worryingly, this is happening when those IP addresses are explicitly NOT bound. e.g. bind interfaces only = yes interfaces = ue0 127.0.0.1/32 ue0: 10.10.0.90, REMOVED::90 lo0: 127.0.0.1, 10.53.0.1/32, 10.53.0.2/32 RSAT DNS will NOT work on the ue0 interfaces, but DOES connect and work on the 10.53.0.[1,2] addresses. There's ANOTHER even NASTIER regression I just found as well: GSS server Update(krb5)(1) Update failed: Miscellaneous failure (see text): Failed to find SKYHORN$@TEST.PVT(kvno 2) in keytab FILE:/var/db/samba4/private/secrets.keytab (aes256-cts-hmac-sha1-96) root@skyhorn:~ # ktutil -k /var/db/samba4/private/secrets.keytab list | grep SKYHORN 1 des-cbc-crc SKYHORN$@TEST.PVT 1 des-cbc-md5 SKYHORN$@TEST.PVT 1 arcfour-hmac-md5 SKYHORN$@TEST.PVT 1 aes128-cts-hmac-sha1-96 SKYHORN$@TEST.PVT 1 aes256-cts-hmac-sha1-96 SKYHORN$@TEST.PVT Yep - the KVNO's being shifted by one in Samba. Which results in SEVERE breakage on the DC. So not only do you have a potential security vulnerability here (clearly access is NOT being properly checked or handled for the dnsserver component) but you have a regression in the KCC that prevents self-managing!
net/samba45 is at 4.5.15 by now and SAMBA_DEFAULT has been lifted to 4.6 in Mk/bsd.default-versions.mk a while ago. This is overcome by events.
Samba versions has very little to do to the bugs in it. Waiting for the user feedback.
(In reply to Timur I. Bakeyev from comment #8) In this case, the last user feedback was almost a year ago. How long do we plan on keeping bugs open for versions that nobody uses? There is nothing wrong with closing it and re-opening it if it is still a problem. Just my 2 cents.
Expired port removed.