A security researcher writes: We believe that we have discovered a potential security vulnerability in the repository’s WINS server “wins hook” feature that can enable unauthenticated remote command execution with the privileges of the Samba process when the hook is configured. Vulnerability Details - Summary: Unsanitized NetBIOS name string from WINS registration packets are concatenated into a shell command and executed via sh -c. An attacker on the network can embed shell metacharacters to inject code. - Relevant code (command construction and execution): ```c // source4/nbt_server/wins/wins_hook.c ... cmd = talloc_asprintf(tmp_mem, "%s %s %s %02x %ld", wins_hook_script, wins_hook_action_string(action), rec->name->name, rec->name->type, (long int) rec->expire_time); ... execl("/bin/sh", "sh", "-c", cmd, NULL); ``` - Data flow (tainted sources → sink): ```c // source4/nbt_server/wins/winsserver.c rec.name = name; // from network packet ... return winsdb_add(winssrv->wins_db, &rec, ...); // source4/nbt_server/wins/winsdb.c wins_hook(h, rec, WINS_HOOK_ADD, h->hook_script); wins_hook(h, rec, WINS_HOOK_MODIFY, h->hook_script); wins_hook(h, rec, WINS_HOOK_DELETE, h->hook_script); ``` - Limitations: NetBIOS names are subject to standard length limitations (typically 15 characters for the name portion). However, these limitations still allow space for command injection payloads using shell metacharacters. Prerequisites for Exploitation - Samba 4 deployment with WINS server functionality enabled - A non-empty `wins hook` script configured in smb.conf (e.g., `wins hook = /path/to/script`) - Network access to send WINS Name Registration requests to the target server (UDP port 137) - The WINS service must be running and accepting registration requests We’re glad to provide additional details or help test fixes. Thank you for your work maintaining Samba.
Created attachment 18700 [details] patch, applying the check as performed by source3 winsserver
Comment on attachment 18700 [details] patch, applying the check as performed by source3 winsserver That looks sane.
(In reply to Gary Lockyer from comment #2) > That looks sane. I am also wondering about a) removing the whole "wins hook" thing from source4, since the putative reason seems to be replication, but we have the wrepl server for that. b) ALSO putting a sanity check earlier, so we do less processing altogether for bad names. The rules (https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/naming-conventions-for-computer-domain-site-ou#netbios-computer-names) aren't strict enough for shell in any case. I guess we can't remove the `sh -c` wrapper and just execlp the thing we're running, because that would break "wins hook = wins-hook-script --args".
I can't get a discount on CVSS 10.0. AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H That's supposing we regard the 15 character payload limit as "interesting challenge" rather than "almost insurmountable hurdle", which would mean 9.0 (AC:H).
(In reply to Douglas Bagnall from comment #3) > a) removing the whole "wins hook" thing from source4, since the putative > reason seems to be replication, but we have the wrepl server for that. My 2ct: Remove it.
(In reply to Douglas Bagnall from comment #6) I am with Volker on this, the best way to fix this is to remove it. An open bug from 12 years ago with one participant is no reason not to delete it, surely the person who reported the bug would have said something by now if a) they were still using 'wins hook' and b) it still didn't work. Microsoft doesn't want anyone to use WINS: https://learn.microsoft.com/en-us/windows-server/networking/technologies/wins/wins-top
> and b) it still didn't work. The problem is it does work. We don't know if anyone uses it, but the fix is simple, works, and matches what we already claim to do in `man smb.conf`. We should do things in this order: 1. backport the fix. 2. remove source4 wins hook from master/4.next. patches imminent.
Created attachment 18716 [details] patch for master This is the patch with tests.
Created attachment 18717 [details] patch removing s4 wins hook from samba 4.next
(In reply to Douglas Bagnall from comment #0) > A security researcher writes: Igor Morgenstern of Aisle Research, for the record.
Created attachment 18718 [details] Patch for master v2 Version 2 patch moves the (temporary) selftest/target/Samba4.pm config change into a more quiescent region, which means the patch will apply as-is at least as far as 4.15. And there are some whitespace changes, not fixing trailing whitespace in the wins.c tests.
Created attachment 18719 [details] post CVE wins hook removal patch v2
Created attachment 18720 [details] advisory v1
This was independently discovered and reported by Marcos Tolosa, today (added to CC). He first reported it to cve.request@mitre.org, who allocated CVE-2025-59520. We will continue to use CVE-2025-10230.
Created attachment 18742 [details] patch for 4.23
Created attachment 18743 [details] patch for 4.22
Created attachment 18744 [details] patch for 4.21
Created attachment 18752 [details] advisory v2
This bug was referenced in samba v4-21-stable (Release samba-4.21.9): 3db699b8e653db0d68bbe07869b8e2c5475481b9 e8639734faa5798bbaf5f7222f25edc071565d99
This bug was referenced in samba v4-22-stable (Release samba-4.22.5): af58459f9519a9b03ada8ec6a3d85331e1a94a7a 540197b92d096b3fdfc66c5103e1a691866d7a6d
This bug was referenced in samba v4-23-stable (Release samba-4.23.2): 8a92384c09dbb17023d420e0c8ae806e9753bc09 0d8929e15443571ec102485319635313e8e80740
Removing vendor CC (so that any public comments don't need to be broadcast so widely) and opening these bugs to the public. If you wish to continue to be informed about any changes here please CC individually.
This bug was referenced in samba v4-23-test: 8a92384c09dbb17023d420e0c8ae806e9753bc09 0d8929e15443571ec102485319635313e8e80740
This bug was referenced in samba v4-22-test: af58459f9519a9b03ada8ec6a3d85331e1a94a7a 540197b92d096b3fdfc66c5103e1a691866d7a6d
This bug was referenced in samba v4-21-test: 3db699b8e653db0d68bbe07869b8e2c5475481b9 e8639734faa5798bbaf5f7222f25edc071565d99
This bug was referenced in samba master: 90b01ac9029169f0a185e74233a71b19a1b4acf0 f25e8ccf0d17fac19f6059ab91534485c8a3ad5a