Stack buffer overflow was discovered in the way samba process user login requests. Function process_logon_packet() uses static buffer outbuf of pre-defined size which is used to store data for reply packet. Writes to the buffer do not check properly for buffer bounds. Only portion of the data stored in outbuf is controlled by remote user and that data should be written to memory occupied by other local buffers. Acknowledgements: Red Hat would like to thank the Samba developers for responsibly disclosing this issue.
This flaw is caused during the login process, which means it's an unauthenticated remote user. This flaw is currently embargoed pending a review by us security types. The file in question can be found here: http://viewcvs.samba.org/cgi-bin/viewcvs.cgi/*checkout*/branches/SAMBA_3_0_MAINT/source/nmbd/nmbd_processlogon.c?rev=25065&content-type=text%2Fplain source/nmbd/nmbd_processlogon.c for those of you with your own copy of the files. Here are the bits we care about: void process_logon_packet(struct packet_struct *p, char *buf,int len, const char *mailslot) { struct dgram_packet *dgram = &p->packet.dgram; pstring my_name; <-- This is a char[1024] fstring reply_name; <-- This is a char[256] pstring outbuf; <-- This is a char[1024] ... q = outbuf; ... q += 2; q += dos_PutUniCode(q, reply_name,sizeof(pstring), True); q += dos_PutUniCode(q, ascuser, sizeof(pstring), True); q += dos_PutUniCode(q, lp_workgroup(),sizeof(pstring), True); As you can no doubt see, q is used incorrectly and can overflow the buffer since they're just adding to it, ignoring the fact that it has a finite size. reply_name and lp_workgroup() are not attacker controlled. They are the server name and server workgroup. They are unlikely to be more than about 15 characters each. ascuser is attacker controlled up to a maximum value of 1024 characters. So this means that the worst we can possibly overflow outbuf is 2 + 256 + 1024 + 1024 = 2306 (there is a bug, the sizeof(pstring) for reply_name should be sizeof(fstring), but reply_name is properly dealt with elsewhere). The stack has a total of 2304 + sizeof(dgram_packet) bytes before we start getting into scary places. It's also worth noting that all the attacker can control is what's in ascuser, which should always end up somewhere in reply_name and my_name variables. This means that even if an admin has an improbably configured server, the worst possible outcome should be a crash from smashing the stack, or writing trash into the dgram pointer.
removing embargo, now public at http://us1.samba.org/samba/security/CVE-2007-4572.html
This issue was addressed in: Red Hat Enterprise Linux: http://rhn.redhat.com/errata/RHSA-2007-1013.html http://rhn.redhat.com/errata/RHSA-2007-1016.html http://rhn.redhat.com/errata/RHSA-2007-1017.html Fedora: updated to fixed upstream version