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.
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
fstring reply_name; <-- This is a char
pstring outbuf; <-- This is a char
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.
removing embargo, now public at
This issue was addressed in:
Red Hat Enterprise Linux:
updated to fixed upstream version