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.
If you put one of your Windows servers on a network I had access to I would be able to show you. I will not release the code publicly (for obvious reasons). Knowledge of these bugs would allow worms/viruses to utterly cripple Microsoft based corporate networks.
If you choose not to believe me without exploit code then that's up to you, but I will not act in an unprofessional way to prove a point.
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:-(.
Err - both Samba-TNG and Samba support this (byte-range locks). Out of the box. We have done for years. I wrote the code:-). That's why you can use Samba for these multi-user apps:-).
It's interesting to understand the reasons for this. It isn't because no one wants it, or no Free Software authors are interested, it's because "the Monopoly" (tm:-) ie. Microsoft doesn't want you to be able to do this, so they don't openly release the internal interfaces you need to use to write such a thing.
They're available under NDA (at least the NFS parts) but the authentication parts are controlled with an iron fist (I don't think there are any replacement LSA modules that will allow NT/W2K/XP to use a NIS or NIS+ server as the sole authentication source). You see, if you could authenticate to a NIS or NIS+ server then you wouldn't need to buy those Windows server licenses and the strategy of leveraging a desktop monopoly into a server one would be in danger...
This is why people are *really interested* in a Samba PDC.
Eloy Paris and Steve Langasek (spelling?) of the Debian Samba community were chasing a user reported core dump bug and they noticed the problem.
They reported it to security@samba.org, and I fixed it that night (with a perfectly correct CVS comment that also failed to point out the security hole:-).
We then worked with the Linux vendors via the vendorsec mailing list to ensure they were all aware of the problem and could issue updates at the same time we announced. Once we'd tested the release, we pushed the button and released...
That is a nice textbook case of how Open Source/Free Software security can work.
"Whats the reason this type of solution doesnt exist already and everybody is running after Microsofts shitty closed protocoll / NDA-enabled sucker solution?"
I'm glad you asked that.
The reason is...... NDA's of course:-):-).
In order to produce client redirector code for Microsoft clients you need to get access to API's that are not available without an NDA.
Do you begin to see the chicken and egg here....:-):-).
No, and that's the problem with the settlement. Not that they should be required to make their code Open Source, but they should be required to publish the protocols in an open manner so that other companies/software projects (ie. NetApp, EMC, Samba) can interoperate.
That was one of the whole points of the legal action remember, to prevent them leveraging their desktop monopoly into the server space.
As you're informing people about DCE here, you should also realize it was a transport independent RPC. It will run over SMB on ports 139 and 445. We implement it.....:-). 135 is only DCE over "raw" TCP. It can be transported in other ways....
POSIX ACLs aren't much more complex than standard UNIX permissions and allow you to do the 2 common cases:
1). Group finance has access + user Jill 2). Group finance has acces but not user fred.
But then again I wrote the Samba POSIX ACL code so I'm biased:-).
Windows ACLs are a complete *nightmare* in comparison. I still don't understand why Sun added an incompatible varient of Windows ACLs to NFSv4 (ie. it's close, but not the same as the real Windows ACLs. The problem is they based the spec. on the Microsoft documentation of how the ACLs work. Big mistake....:-).
Jerry, tpot and I aren't worried about this. I spoke to Bruce at LinuxWorld before he left, I understand why he is leaving and I'm sorry. I wish he wasn't, but it doesn't affect what we do with Samba (mainly fix printing bugs at the moment it seems:-):-).
That's because we've known about this exploit for over 2 years. Yes we told them. I had a linux executable on my laptop that would do this for the Windows 2000 launch show (to which I was invited to give a talk:-). They didn't let me connect to the show network:-). I guess it takes an exploit in the wild for them to fix *anything*. So much for the new "focus on security".....
Yeah but the design of Samba is such that if you do this you only irritate yourself. If you do this on a Windows box you irritate everyone else using it as a fileserver.
This is a very astute comment (IMHO). The real reason behind this is to raise FUD in the minds of vendors looking at Samba on Linux as an alternative to Microsoft's server appliance kit.
Doesn't matter if it's legal or if the patent claims are valid. It's to get the CEO's of appliance companies to go into their engineering dept. and say "see, we should have licensed from Microsoft to be *safe*".
It's all about the dollars and control of the vendors........
Slashdot Mirror
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 you put one of your Windows servers on a network
I had access to I would be able to show you. I will
not release the code publicly (for obvious reasons).
Knowledge of these bugs would allow worms/viruses to
utterly cripple Microsoft based corporate networks.
If you choose not to believe me without exploit code
then that's up to you, but I will not act in an
unprofessional way to prove a point.
Jeremy Allison,
Samba Team.
I could show you MS bugs that we've known about for
:-).
more than 8 years.
Yes, they crash your MS SMB server. Yes, we've told
Microsoft about them.
Microsoft don't always fix bugs if there are no active
exploits against them and knowledge of them is limited.
I guess they just trust that we don't release exploits
Jeremy Allison,
Samba Team.
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.
Err - both Samba-TNG and Samba support this (byte-range :-). That's why you can use Samba for these multi-user :-).
locks). Out of the box. We have done for years. I wrote the
code
apps
Jeremy.
It's interesting to understand the reasons for this.
It isn't because no one wants it, or no Free Software
authors are interested, it's because "the Monopoly" (tm:-)
ie. Microsoft doesn't want you to be able to do this, so
they don't openly release the internal interfaces you need to
use to write such a thing.
They're available under NDA (at least the NFS parts) but
the authentication parts are controlled with an iron fist
(I don't think there are any replacement LSA modules that
will allow NT/W2K/XP to use a NIS or NIS+ server as the
sole authentication source). You see, if you could authenticate
to a NIS or NIS+ server then you wouldn't need to buy those
Windows server licenses and the strategy of leveraging a
desktop monopoly into a server one would be in danger...
This is why people are *really interested* in a Samba PDC.
Regards,
Jeremy Allison,
Samba Team.
Because it doesn't crash anymore when you :-).
send it a packet that would overflow the buffer
Cheers,
Jeremy Allison,
Samba Team.
If you can craft an exploit for this, please
mail it to me and we'll talk about getting you
working full time on Samba.
Yes, it could crash smbd (for the authenticated
user) but causing it to run code is another matter.
We couldn't work out how to do that, but hey, I'm
willing to believe you might know how. Show me.
Or are you just mouthing off with no expertise to
back it up ?
Regards,
Jeremy Allison,
Samba Team.
Eloy Paris and Steve Langasek (spelling?) of the Debian
:-).
Samba community were chasing a user reported core dump bug
and they noticed the problem.
They reported it to security@samba.org, and I fixed it that
night (with a perfectly correct CVS comment that also failed
to point out the security hole
We then worked with the Linux vendors via the vendorsec
mailing list to ensure they were all aware of the problem
and could issue updates at the same time we announced. Once
we'd tested the release, we pushed the button and released...
That is a nice textbook case of how Open Source/Free Software
security can work.
Cheers,
Jeremy Allison,
Samba Team
"Whats the reason this type of solution doesnt exist already and everybody is running after Microsofts shitty closed protocoll / NDA-enabled sucker solution?"
:-) :-).
:-) :-).
I'm glad you asked that.
The reason is...... NDA's of course
In order to produce client redirector code for Microsoft clients you need to get access to API's that are not available without an NDA.
Do you begin to see the chicken and egg here....
Cheers,
Jeremy Allison,
Samba Team.
It's a fair cop 'guv :-). Good point. Ok, I don't care what :-) :-).
their *internal* protocols are
Thanks,
Jeremy Allison,
Samba Team.
Computer science 101 time :-).
:-).
API's are *not* protocols. I don't care what their API's are, I don't program under Win32.
I care what bytes come out from and go into the *network* from a Windows computer as a protocol description.
You know, that rather thick blue piece of string hanging out the back of your computer
Jeremy Allison,
Samba Team.
No, and that's the problem with the settlement. Not that they should be required to make their code Open Source, but they should be required to publish the protocols in an open manner so that other companies/software projects (ie. NetApp, EMC, Samba) can interoperate.
:-).
That was one of the whole points of the legal action remember, to prevent them leveraging their desktop monopoly into the server space.
Repeat after me... competition is *good*
Jeremy Allison,
Samba Team.
Close but not correct.
:-). 135 is only DCE over "raw" TCP. It can be transported in other ways....
As you're informing people about DCE here, you should also realize it was a transport independent RPC. It will run over SMB on ports 139 and 445. We implement it.....
Jeremy Allison,
Samba Team.
Yes I do, but I'm not telling :-). Read the Samba source code :-).
Jeremy.
Software patents. The author is frightened of a
patent held by Network Appliance that seems to
cover Tux2 and so has discontinued work on it.
Never mind he has prior art, they have more
money and lawyers. Welcome to software
development in the USA in the 21st Century....
Jeremy Allison,
Samba Team.
POSIX ACLs aren't much more complex than :
:-).
:-).
standard UNIX permissions and allow you to do
the 2 common cases
1). Group finance has access + user Jill
2). Group finance has acces but not user fred.
But then again I wrote the Samba POSIX ACL
code so I'm biased
Windows ACLs are a complete *nightmare* in
comparison. I still don't understand why Sun
added an incompatible varient of Windows ACLs
to NFSv4 (ie. it's close, but not the same as
the real Windows ACLs. The problem is they based
the spec. on the Microsoft documentation of how
the ACLs work. Big mistake....
Regards,
Jeremy Allison,
Samba Team.
Jerry, tpot and I aren't worried about this. I spoke to Bruce :-) :-).
at LinuxWorld before he left, I understand why he is leaving
and I'm sorry. I wish he wasn't, but it doesn't affect what
we do with Samba (mainly fix printing bugs at the moment it
seems
Jeremy Allison,
Samba Team.
That's because we've known about this exploit for over 2 years. Yes we told them. I had a linux executable on my laptop that would do this for the Windows 2000 launch show (to which I was invited to give a talk :-). They didn't let me connect to the show network :-). I guess it takes an exploit in the wild for them to fix *anything*. So much for the new "focus on security".....
Jeremy Allison,
Samba Team.
Yeah but the design of Samba is such that if you do this you only irritate yourself. If you do this on a Windows box you irritate everyone else using it as a fileserver.
Jeremy Allison,
Samba Team.
Yes we will. Please see this statement for details.
Jeremy Allison
Samba Team.
Nope, I thanked Richard Stallman for creating the GPL and the FSF for helping us with legal issues :-).
:-) :-).
:-) :-)
And I had to wear a suit
Here is proof
Jeremy Allison,
Samba Team.
No, you're not blind.
It means that the interfaces needed for write such a thing (NFS client for Windows 2000) are not documented freely by Microsoft.
You're heard of hidden API's in Windows ? This is the perfect example of one (the interface to the client redirector code).
Jeremy Allison,
Samba Team
This is a very astute comment (IMHO). The real reason behind this is to raise FUD in the minds of vendors looking at Samba on Linux as an alternative to Microsoft's server appliance kit.
Doesn't matter if it's legal or if the patent claims are valid. It's to get the CEO's of appliance companies to go into their engineering dept. and say "see, we should have licensed from Microsoft to be *safe*".
It's all about the dollars and control of the vendors........
Regards,
Jeremy Allison,
Samba Team.
We (the Samba Team) don't think Samba infringes on these patents. We've looked at them.
The problem is it doesn't matter what we think, it matters what lawyers think of this.
We're currently getting a legal opinion on this and will post a more complete statement once we've done so.
Regards,
Jeremy Allison,
Samba Team.