It was reported [1] that two vulnerabilities were found in Samba's smbd that would allow an attacker to trigger a null pointer dereference or an unitialized variable read by sending a specific 'Sessions Setup AndX' query. Successful exploitation of these issues would result in a denial of service. The upstream bug report [2] has a patch. [1] http://www.stratsec.net/Research/Advisories/Samba-Multiple-DoS-Vulnerabilities-(SS-2010-005) [2] https://bugzilla.samba.org/show_bug.cgi?id=7254
Created attachment 415804 [details] copy of the first provided reproducer (NULL deref)
Created attachment 415805 [details] copy of the second provided reproducer (OOB read)
I'm not sure how much value these reproducers are. On Fedora 12 I have samba 3.4.7 which is supposed to be vulnerable but I see nothing in the log.smbd file, and samba runs fine. I do see something in the logs for Samba 3.0.33 as provided in Red Hat Enterprise Linux 5, but again no crash: [2010/05/21 17:45:13, 0] smbd/process.c:switch_message(922) Unknown message type 65! [2010/05/21 17:45:13, 0] smbd/reply.c:reply_unknown(594) unknown command type (SMBunknown): type=65 (0x41) [2010/05/21 17:45:13, 0] lib/util_sock.c:write_data(562) write_data: write failure in writing to client 192.168.250.54. Error Broken pipe [2010/05/21 17:45:13, 0] lib/util_sock.c:send_smb(761) Error writing 51 bytes to client. -1. (Broken pipe) [2010/05/21 17:45:22, 0] lib/util_sock.c:write_data(562) write_data: write failure in writing to client 192.168.250.54. Error Connection reset by peer [2010/05/21 17:45:22, 0] lib/util_sock.c:send_smb(761) Error writing 318 bytes to client. -1. (Connection reset by peer) So I'm not sure if the reproducers are lame/reduced or whether the vulnerable versions are incorrect (the report indicates "Samba <=3.4.7 and Samba <= 3.5.1" as vulnerable (with 3.4.8 and 3.5.2 being fixed)).
(In reply to comment #0) > The upstream bug report [2] has a patch. Does the upstream bug linked in stratsec advisory cover both issues? Based on 3.4.8 release notes, relevant upstream bugs and commits rather seem to be: NULL pointer dereference: https://bugzilla.samba.org/show_bug.cgi?id=7229 http://git.samba.org/?p=samba.git;a=commitdiff;h=25452a2268ac7013 uninitialized variable read: https://bugzilla.samba.org/show_bug.cgi?id=7254 http://git.samba.org/?p=samba.git;a=commitdiff;h=9280051bfba33745
This hardly looks like a DoS, given all you end up killing is your own connection. And it doesn't seem this bug is exploitable in any other way. I would drop the "security" curtain and close this once we rebase on new versions that include the patch.
This has been assigned CVE-2010-1635 (but no distinction made if that assignment is for one or both of the issues).
CVE-2010-1635 is for the NULL pointer dereference vulnerability, and CVE-2010-1642 has been assigned to the OOB read vulnerability.
(In reply to comment #3) > I'm not sure how much value these reproducers are. On Fedora 12 I have samba > 3.4.7 which is supposed to be vulnerable but I see nothing in the log.smbd > file, and samba runs fine. I can reproduce NULL pointer dereference crash with 3.5.1 using reproducer in comment #1 (note: stratsec advisory has reproducers mixed-up and labels that reproducer as being for the uninitialized variable read issue). NULL pointer deref occurs in the code that was added in this commit: http://git.samba.org/?p=samba.git;a=commitdiff;h=c116652a3050a854 The code does not exist in 3.4.x, older versions are even more different. In 3.4.x, smb_splice_chain is called and it correctly handles NULL req->chain_outbuf correctly and reallocs the buffer. As noted in comment #5, it's limited to per-connection smbd child crash and does not affect smbd service availability. The worst impact seem to be creation of smbd process core file (enabled by default, see "enable core files" in smb.conf).
(In reply to comment #8) > The code does not exist in 3.4.x, older versions are even more different. In 3.3.x versions, this triggers smb_panic() call that is used when certain error conditions are detected. Newer (and older) versions do not use smb_panic() in those cases.
The second issue is reproducible on 3.4.x and 3.5.x, but I'd call it out-of-bounds read, rather than uninitialized variable read. Input packet specifies the length of a data block included in the packet. smbd uses this value instead of the number of bytes that were actually included in the packet. The value is used to adjust pointer used for reading remaining fields of the packet buffer and possibly reach unmapped memory and trigger segmentation fault. The value is unsigned 16-bit, so 0xffff is the maximum value. Due to this constraint, reproducibility depends on the actual memory layout of the smbd process. Reproducer does not trigger crash on older samba versions. As with the previous issue, it does not affect smb service availability.
Closing this as not a security bug, based on previous comments. Statement CVE-2010-1635: Not vulnerable. These issues did not affect the versions of samba as shipped with Red Hat Enterprise Linux 3, 4, or 5. Statement CVE-2010-1642: Red Hat does not consider this to be a security flaw. This issue can cause smbd per-connection child process crash, resulting in the termination of an attacker's connection. Availability of the smb service is not impacted.