Samba gets hit again
It looks like we're dealing with yet another in a long series of mundane security holes. There are a couple of aspects to this one that make it interesting, however:
- The bug has apparently been there for some eight years. Despite
numerous security audits and constant maintenance, this vulnerability
managed to lurk undetected for a long time. The code looked
(to a casual inspection) like it should be correct - it used a bounded
string copy function. A deeper look was necessary to determine that
the bound was wrong. The relatively subtle nature of the bug, along
with the fact that the relevant code "just works" and hadn't needed
much attention for some time, helped this bug to escape detection.
It is also true, however, that finding these vulnerabilities is just hard. Even after a serious audit, you can never be sure that no problems remain.
- This bug was apparently being actively exploited before its discovery by the "white hats." Free software tends to generate a lot of security updates, but relatively little damage results from all those vulnerabilities. The reason for that, of course, is that problems tend to be found by people who will fix them, rather than those who will exploit them. There will always be exceptions, though, and this bug is one of them. It also didn't help, of course, that Digital Defense posted its advisory - and working exploit code - before the Samba team was able to react to the problem.
In the end, the conclusions are the same: apply updates quickly, and do not
expose network services to the Internet if you can avoid it.
Posted Apr 10, 2003 2:43 UTC (Thu)
by Peter (guest, #1127)
[Link]
Don't be so hard on Digital Defense. They told the Samba Team about this several days in advance. The Samba Team, in turn, sent their 2.2.8a patch to the vendors on Friday night, and announced it to the public Monday. If the Digital Defense announcement came before the Samba announcement, it was a mere synchronisation problem; they weren't just pulling a fast one. The Samba Team did jump the gun on some of the vendors; this was a conscious decision because of the active exploit.
Posted Apr 10, 2003 9:02 UTC (Thu)
by beejaybee (guest, #1581)
[Link] (7 responses)
(1) is it ever sensible to deploy in a mission-critical environment a protocol owned by Microsoft, whose security record is (to say the least) not good? (2) does it matter, given that RIAA is going to stamp down on everyone using SMB, because it facilitiates distribution of possibly copyrighted material?
Posted Apr 10, 2003 9:23 UTC (Thu)
by evgeny (guest, #774)
[Link] (2 responses)
Who was talking about "mission critical" and why security holes are ok otherwise? > a protocol owned by Microsoft, whose security record is (to say the least) not good? What's wrong about the protocol? The bug was in an (OS) _implementation_.
Posted Apr 12, 2003 1:07 UTC (Sat)
by xorbe (guest, #3165)
[Link] (1 responses)
Posted Apr 17, 2003 19:37 UTC (Thu)
by barrygould (guest, #4774)
[Link]
If there is a bug in Windows SMB implementation that that would crash Windows, should samba crash? NO! If there was a bug in a reference TCP/IP implementation, should all implementations crash? NO!
Posted Apr 10, 2003 9:27 UTC (Thu)
by melo@simplicidade.org (subscriber, #4380)
[Link] (1 responses)
The code of samba is not derived from any m$ code. The bug is a original open-source Yes, SMB is not a very good protocol, but this was an implementation bug, as far as I could Best regards,
Posted Apr 10, 2003 21:46 UTC (Thu)
by minichaz (guest, #630)
[Link]
Cheers,
Posted Apr 15, 2003 18:18 UTC (Tue)
by rwmj (subscriber, #5474)
[Link] (1 responses)
Rich.
Posted Apr 17, 2003 10:45 UTC (Thu)
by MGPoolman (guest, #3469)
[Link]
Mark
Posted Apr 10, 2003 11:28 UTC (Thu)
by bockman (guest, #3650)
[Link] (1 responses)
This is wy damage control techniques (like stack protection kernel patches) should be more supported, IMO.
Posted Apr 10, 2003 22:03 UTC (Thu)
by bastiaan (guest, #5170)
[Link]
They do generate a false sense of security and thereby make it seem less urgent for the community to develop a proper solution. It's ridiculous that after thirty years buffer overflows still pose a security problem.
Posted Apr 10, 2003 18:08 UTC (Thu)
by nas (subscriber, #17)
[Link]
Samba gets hit again
It also didn't help, of course, that
Digital Defense posted its advisory - and working exploit code - before the Samba team was able to react to the problem.
Two things spring to mind:Samba gets hit again
> is it ever sensible to deploy in a mission-critical environmentSamba gets hit again
But the Samba team has to be bug-for-bug compatible with another OS'es buggy implementation...
Samba gets hit again
That is wrong.Samba gets hit again
Although Microsoft security is, to be gentle, lousy in most ways, even I who use and preach Samba gets hit again
samba for corporate environments for the last 5 years, cannot see why m$ is to blame on
this one. :)
creation :).
understand.
Though this particular error is implementation related, SMB is flawed protocol (certainly from a security point of view). Anyone exposing a Samba server (or any other type of SMB server) to the internet is either insane or stupid. Ports 137, 139 and 445 (I think thats right) should be blocked by any semi-decent firewall.Samba gets hit again
Charlie
The SMB protocol is a model of security compared to typical implementations of NFS, where a user with root on any client can trivially read and modify anyone's file.
Samba gets hit again
Not so. As long as the server is properly configured, root on a client does *not* get root on the server and has permissions of "other" on the nfs mounted systems. AFAIK this is the default behaviour, to allow root privileges you have to set "NOROOTSQUASH" or somesuch in /etc/exports.Samba gets hit again
It is also true, however, that finding these vulnerabilities is just hard. Even after a serious audit, you can never be sure that no problems remain.
Samba gets hit again
I still do not understand why the various anti-buffer-overrun kernel patches have not found a way in the official kernel tree, at least as experimental and compiled-out by default. The 'official' answer (as far as anything is official in OS) is : "they don't fix completely the problem, and they could generate a false sense of security". But the same could be said for a locked door, and I don't see anybody leaving the door open because of that.
Samba gets hit again
But of course this is the 'Linus approach', you can always switch to OpenBSD if you do want stack protection.
BTW stack protection doesn't help anything against this particular security vulnerability: the affected buffers are on the heap.
I'm convinced that you cannot write secure code using C's array types. Programmers need range checking. Also, the array size needs to be keep
with the array. Passing a pointer to the array and the the array size seperately is a recipe for disaster.
There are string libraries out there that do this. More people ought to use them.
Need range checked array types