Bug 294631 (CVE-2007-4572)

Summary: CVE-2007-4572 samba buffer overflow
Product: [Other] Security Response Reporter: Tomas Hoger <thoger>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: kreilly, samba-bugs-list, ssorce
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: impact=moderate,source=redhat,public=20071115:1400,reported=20070914
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-01-14 09:57:05 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On: 350721, 350731, 350741, 350751, 350761, 350771    
Bug Blocks:    

Description Tomas Hoger 2007-09-18 08:35:54 EDT
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.


Red Hat would like to thank the Samba developers for responsibly disclosing this issue.
Comment 3 Josh Bressers 2007-10-29 11:23:56 EDT
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:

source/nmbd/nmbd_processlogon.c for those of you with your own copy of the

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

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.
Comment 6 Mark J. Cox (Product Security) 2007-11-15 09:36:10 EST
removing embargo, now public at
Comment 7 Red Hat Product Security 2008-01-14 09:57:05 EST
This issue was addressed in:

Red Hat Enterprise Linux:

  updated to fixed upstream version