Slashdot Mirror

they don't like introducing "new" things

A slight correction, they like to introduce new things when it suits them. Why the rewrite of SMB into SMB2? Well, it has some technological advantages you would expect but according to Wikipedia:

SMB 2 has two big benefits to Microsoft. The first is clear intellectual property ownership. SMB 1 was originally designed by IBM and was shipped on a wide variety of non-Windows operating systems such as SCO Xenix, OS/2 and DEC VMS (Pathworks). It was partially standardised by X/Open and also had draft standards for IETF which lapsed. (See http://ubiqx.org/cifs/Intro.html for historical detail).

The second benefit is a clean break. Microsoft's SMB1 code has to work with a huge variety of SMB clients and servers. A large number of items in the protocol are optional (such as short and long filenames), there are many infolevels for commands (selecting what structure is returned to a particular request), Unicode was a later addition etc. With SMB2 there is significantly reduced compatibility testing (currently only other Windows Vista clients and servers). Additionally the code is a lot less complex since there is far less variability (e.g. there is no need to worry about having Unicode and non-Unicode code paths as SMB2 requires Unicode support).

So you can see they like to introduce new things when it means they have clear intellectual property ownership rights over it and also a lot less work for them. They also don't have to be backwards compatible with their own products.

While SAMBA 4.0 has experimental support for SMB2 interfacing, I'm guessing the "clear intellectual property" could spell trouble moving forward for Tridgell and the SAMBA team.

I tend to keep things simple. I wrote Implementing CIFS in very plain HTML. Yes, by hand. No, I didn't flail myself with birch bows or kneel on jacks just to prove my inner strength. It was honestly the simplest, easiest way to format everything. Mind you, I had a very supportive publisher.

...and I used to write college papers in Runoff, so I'm used to that kind of markup.

...and I would probably want to learn Docbook if I were to do it all over again.

CIFS was and is a proprietary protocol.

No it isn't. SMB was and is proprietary, CIFS is an open standard based on SMB and a several valid RFCs that encapsulate the important parts of NetBIOS.

So, you mean that they abuse their economical power... But it is ok, since they do that with a nice GUI? Or are you saying (falsely) that Microsoft has not extended those protocols? Because they have extended (or tried) almost all of them, DNS being the only exception, and irrelevant since they already tried to extend TCP.

• AD can serve a standard DNS domain (even if mixed with Linux BIND servers), including an LDAP backend and dynamic updates: http://support.microsoft.com/kb/317590
  
• AD can also serve Kerberos for Linux clients (in a standard way): (here), it can also do RADIUS as well.
  
• AD is LDAP compliant so use can also use nss_ldap to grab user information on Linux system from it
  
• Linux and Windows nodes can perform two directional file sharing via standard* CIFS protocol
  
• AD (with addition of certificate services) can serve as s X509 Certificate Authority.
  
• AD + Exchange will understand SMTP, SMTP-AUTH (over LDAP), POP3, IMAP, IMAPS, NTTP protocols (additional web based access is also provided).
  
• With Windows Server 2003 R2, AD can also serve standard NIS, NFS, CUPS and similar UNIX protocols.
  
• If you include non standard (but known) protocols in the mix, Windows and Linux machines can also interoperate via DFS (Distributed File Sharing), RPD (Terminal Services), etc.
  
  
  The required setup is done less than an hour, and will require a (less competent) system administrator for maintenance in the long run.
  
  (It can be argued that the Linux side will require a more educated - i.e: more expensive - system administrator, and preparation of many site specific scripts and configurations - yet this may not seem objective for some people).
  
  Don't misunderstand I'm not proposing converting all the systems to AD. I'm telling AD is also a fine solution based on open protocols.

D'oh. Found my answer:

http://ubiqx.org/cifs/SMB.html

"Like NetBIOS, the Server Message Block protocol originated a long time ago at IBM. Microsoft embraced it, extended it, and in 1996 gave it a marketing upgrade by renaming it "CIFS"."

Short answer: I have it backwards. SMB is the "open" one. CIFS is what you get after MS does their embrace and extend act on it. Ooops. Sorry for the misinformation!

"Big picture view, I do believe Microsoft to be a monopoly. I do believe there needs to be some sort of repercussion for it but I think anyone asking them to give up THEIR intellectual property that they have developed is just proving their point... they are the best."

According to the Free Software Foundation of Europe Microsofts implementation of the *standard* server SMB protocol: "... a number of incompatibilities deliberately introduced in pre-existing protocols and then altering them with the aim of prohibiting interoperability." To extend a standard protocol is not inventive, it is evolutionary. The protocol is not secret, http://ubiqx.org/cifs/SMB.html, the non-standard Microsoft implemenation is. The EU simply says this is an obvious abuse of monopoly hurting competition and must stop. And no, seeing one specific implemenatation does not easily get you far in understanding how Microsoft specifically has extended the protocol itself. And by the way, 12000 pages of documenation? How can the Microsoft specification be that much longer than the original specification?

Also it may be useful to look at the wikipedia reference on the SMB protocol:
http://en.wikipedia.org/wiki/Server_message_block
IBM, not Microsoft, specified the SMB protocol. What Microsoft did, inheretnly to stay incompatible with competitors server products and illegaly use their desktop monopoly, was to extend the SMB protocol. Andrew Tridgell which leads the Samba team has on several occasions noted that it seems like the changes made often has no other purpose than to make the Microsoft SMB implemenation incompatible with other implemenations.

According to at least one of the Samba developers documentation wouldn't be useful anyway:

"There can't be a specification that's worth anything," says Jeremy Allison, joint lead of the Samba Project.

"The source code itself is the specification . The level of detail required to interoperate successfully is simply not documentable - it would produce a stack of paper so high you might as well publish the source code."

(Source - Found via the Implementing CIFS book)

Wikipedia, more in-depth discussion here.

Lan Manager passwords have a maximum size of 14 ascii characters.
NTLM passwords have a maximum size of 128 unicode characters.
Windows 9x uses Lan Manager hashes unless upgraded with the Active Directory Client, in which case it uses NTLM v2.
Windows NT (and derivatives) have always used NTLM passwords; NT has always supported passwords up to 128 unicode chars, if you disable storing Lan Manager hashes. NTLM v2 was first introduced in NT4 sp3.

Here's a Microsoft page describing user authentication in detail for NT versions 3.1 to 4.0.
Here's a good reference page about SMB, with a section about Windows network authentication-- scroll down to section 2.8.

Microsoft's file sharing uses NETBIOS for naming, etc, but there are other elements to it, too. Microsoft published a draft to the IETF for CIFS (formerly SMB). It's only a subset of the functionality that Windows actually supports, and it was chock full of errors and omissions. There were also several books written about SMB. The earliest I can find is Protocols for X/Open PC Interworking: SMB, Version 2, published October 1992. The first version may have been published more than two years earlier, in January 1990, but I'm having difficulty finding that information. The Samba site says that the first version, developed in 1992, was based on reverse engineering the wire protocol of the MS-DOS SMB client. The later versions may have made use of this other documentation.

Excluding Kerberos authentication (which I should know more about, but don't) there are *two* hash types: LM and NTLM.

The LM Hash is used when performing LM challenge/response.

The NTLM Hash is used when performing NTLM, LMv2, and NTLMv2 challenge/response. Note that LMv2 is simply a degenerate case of NTLMv2.

I've written a book with a whole whoppin' big section on LM and NTLM auth: http://ubiqx.org/cifs/SMB.html#SMB.8.

Scroll down for information on specific auth protocols.

Chris -)-----

The LM and NTLM hashes are what really need to be protected. They are (as I keep saying...sorry I'm on a rant) password equivalent. Once someone has the hash the password itself is of minimal additional value.

Note that it is fairly easy to discover the LM Hash given an LM challenge/response pair. That's why the LM challenge/response should not be allowed on the wire.

It's also possible to reverse the hash from the NTLM, LMv2, and NTLMv2 challenge/response protocols, but it gets progressively harder as the algorithms improve.

It's all documented.

Chris -)-----

LAN Manager was more than just the password system, and it dates back well before W95.

hash = a way of storing passwords without leaving the password on the disk. You encrypt the password into a hash code and store that instead. You can't unencrypt it to derive the password but you can check a password guess by encrypting the guess the same way. If the guess hash == the password hash, you get in.

Yes, a good explanation, except... Unix systems generally add a bit of "Salt" to the hash so that the hash itself is not password equivalent. I have to be honest and state that I'm not sure exactly how that works. I'll have to do some reading in Schneier tonight. :)

The best part is, you don't have to keep the hash code a secret, because it's not the hard part. You're not asked to provide the hash value; you're asked to provide something that hashes to the value. So you can store it on the disk and even send it out over the LAN where it can be sniffed.

Nope. This may be true if salt is used, but there is no salt used when creating the LM or NTLM hashes. That, combined with the mechanism used for network authentication, result in this oft-forgotten fact: Windows LM and NTLM Hashes are password equivalent. They must be protected because, basically, they are the passwords!

That's very convenient: you can cache the hash code on every computer without having to trouble the central server to do the work. You don't want to send the password over the network (where it could be sniffed); nor is sending the hash code to the server for verification (because that could be spoofed). You distribute the hash to each computer, then let it decide if the password guess is correct. The password never goes across the network.

Ouch...no. That works for public key cryptography but you're describing a symmetric key system. Password hashes must be protected, even those with salt. That's why the password hashes on Unix systems are stored in the shadow files instead of the passwd file.

I've already described challenge/response in other posts on this topic. I'm in major fud-fight mode here. Read the docs: http://ubiqx.org/cifs/SMB.html#SMB.8.

Chris -)-----

If you have the LM Hash, and the server accepts LM Authentication, you don't need the password. At all.

Likewise, if you have the NTLM Hash, and the server accepts NTLM, NTLMv2, or LMv2 authentication, then you don't need the password.

The hashes are password equivalent.

I've written it all up in my online book (slashdot review), but...

Basically, the hashes are generated with no salt...nothing to obfuscate them. The algorithm used to log in is challenge/response:

• The server sends a random 8-byte string (the "challenge").
• Both client and server encrypt the challenge using the LM and/or NTLM Hash, not the password.
• The client sends its result (the "response") back to the server.
• The server compares results. If they match, the server grants access.

So... The hash is not exposed on the wire. It has to be reversed from the challenge and response. That's possible (and fairly easy with LM Auth), but it's got little to do with the password/LM Hash database.

The only way to use the LM Hash database to reverse the challenge/response is to use it as a hash dictionary.

Chris -)-----

http://ubiqx.org/cifs/SMB.html#SMB.8.3

1. They are not exposed on the wire.
2. They are password equivalent.

Note that the hash is not sent over the wire.

That's important, because (large databases and rainbow tables aside) you don't need the original password. The hash is computed with no salt, so it is completely password-equivalent. Someone with access to the above documentation and the LM or NTLM hash has all they need in order to fake a login.

Chris -)-----

SMB was used in Pathworks, but was originally conceived and developed by Dr. Barry Feigenbaum at IBM. Not sure what the first available implementation was; could have been Pathworks.

I see it's published under the Open Publication License but it appears I cannot download it and read it on my Palm on the train -- it's a web-only affair. Sure, I could spider the site but I haven't done that yet; I prefer entire books (I use MobiPocket).

At any rate, enjoy the link!

If you use NetBEUI, then use *only* NetBEUI.
If you use NWLINK, then use *only* NWLINK.
etc.

See the heading "Prolific Protocol Bindings" in Section 3.7.1 of the online version of the book.

In short, SMB was borrowed from IBM. Here (near the top of the page) is a brief history.

Hate to be a nitpicker, but SMB/CIFS is a technology developed by IBM in 1984.

I'm going to be an even bigger nitpicker. SMB is the technology developed by IBM. CIFS is an extension to SMB developed by Microsoft though cynical people say that CIFS is more a marketing exercise than a new protocol.

Info on SMB and CIFS.

um no
it does NOT directly run on tcp/ip.

Regarding the "MS altered standards"... SMB itself has never been a standard. Microsoft's implementation of STD 19 (RFC 1001/1002) is very broken, however, and yes we do copy them on that. (I'm working on documenting their implementation errors.) Others, like their Kerberos PAC manglement and the evil they've done to/with DCE/RPC... again, this is a valid perspective and one that has not been lost on us.

On the plus side, by doing the work we do we expose some of these problems, and hopefully work toward raising awareness.

Thanks.

Chris Hertel -)-----
Samba Team