Slashdot Mirror
Samba Exploit Discovered, Fixed
An anonymous reader submits: "Digital Defense reported a remote root vulnerability in Samba that has existed in Samba source code for over 8 years. If it hadn't been caught from a wild packet capture, who knows how many more years it might have gone on. Fixes for this, and at least three other vulnerabilities have been fixed today. This is a serious threat to many thousands of people.. Did you plan to spend your Monday upgrading to Samba 2.2.8a?"
elijahao supplies some more information: "All stable versions are affected (2.x), but the 3.0 series is not. Here is a link to the News page. Check out a mirror near you to get the Source or Security patches from 2.2.7a, 2.2.8, or 2.0.10."
A FreeBSD Security Advisory has been issued and the samba port has been updated to the fixed version:
:)
samba 2.2.8a
Update 2.2.8 -> 2.2.8a.
Submitted by: dwcjr (MAINTAINER)
I already updated my installation 4 hours ago, the FreeBSD folk are fast
This is what is fixed by the update:
(1) Sebastian Krahmer of the SuSE Security Team identified
vulnerabilities that could lead to arbitrary code execution as root,
as well as a race condition that could allow overwriting of system
files. (This vulnerability was previously fixed in Samba 2.2.8.)
(2) Digital Defense, Inc. reports: ``This vulnerability, if exploited
correctly, leads to an anonymous user gaining root access on a Samba
serving system. All versions of Samba up to and including Samba 2.2.8
are vulnerable. Alpha versions of Samba 3.0 and above are *NOT*
vulnerable.''
Well security problems like this tend to come in pairs :-).
:-(.
(I'm just hoping not in threes
Once one gets discovered then people look for others in
the same project.
The first one was found by a SuSE audit, and we went through
and fixed all related code. This one was found 'in the wild'
so to speak. I'm not sure how long the cracker community
has known about this one.
I'm to blame as both were in code I wrote a long time ago
Jeremy Allison,
Samba Team.
I think it's better that these bugs are found, publicized and patched in a professional manner (like Samba, Sendmail, etc.) then see a company sit on an exploit for a while and state that their products are unbreakable (Oracle) or secure (Microsoft)... even if it's a bug a day. So long as it's fixed, people are notified about it.
As far as people patching them, that's another topic altogether.
Almost every software has bugs... be it disclosed or not disclosed.
Actually I have been thinking about this very fact w.r.t.
these recent vulnerabilities.
The problem was that the written code *worked*, as in if
it was given well-formed SMB packets it behaved correctly,
even though it was in a little used part of the code.
Because it worked 'out of the box' as it were, with
Windows clients there was little reason to examine it.
It's code that has a problem that gets looked at first.
I'm not trying to absolve myself of blame, after all, I
wrote the buggy code, but there was a reason that no one
needed to look at it for 8 years or so.
Jeremy Allison,
Samba Team.
If this had been a bug for a MS product, you'd be slamming MS hard. But now all I see is a mountain of whiny, hypocritical comments when it is in the non-MS camp.
Yes, Apple are working on this. I ported the fix to
their codebase this morning and mailed it to them.
Jeremy Allison,
Samba Team.
No, we're not keeping them secret. Microsoft know, we
told them. The flaws are in their code. If you had access
to Microsoft source code and could fix them, I'd tell you.
But you don't, that's the problem. All you could do is
create mischief with the knowledge. I don't see why I have
any professional obligations to help you with that.
Jeremy Allison,
Samba Team.
The problem is that there are 20,000 different people with access to these servers, both administrative and student, and you really can't trust all of them not to try to r00t your b0>.
There is *never* a good reason to release exploit code (IMHO).
It only allows those with no talent (the script kiddies)
to cause trouble for people trying to maintain systems.
Inform the vendor, if the vendor does nothing, tell the
world it is broken, demo your exploit to some journalists
if you like.
But releasing exploit code is the programming equivalent
to leaving a pile of fully loaded weapons outside a school.
Jeremy Allison,
Samba Team.