Modify

Opened 6 years ago

Closed 6 years ago

Last modified 5 years ago

#1325 closed bug (fixed)

NTLMv2 authentication (Windows 7 file sharing) does not work on 2.0g

Reported by: matthijs Owned by:
Priority: normal Milestone: Firmware 2.3.7.1
Component: fon-base-firmware Version: 2.3.7.0 (Paco)
Severity: normal
Cc: Hardware: 2.0g (FON2202)

Description

It seems there is an issue with Samba authentication, specifically on 2.0g. I've found that connecting from Windows 7, or a recent Linux system (both through Nautilus and smbclient) always gives a permission denied. On 2.0n, or when using Windows XP, everything works as expected.

This bug seems to be present in all versions (tested back to 2.2.5.0).

Closer investigation shows that Windows 7 (and presumably also Vista) uses NTLMv2 authentication by default, while Windows XP uses the older NTLMv1. This difference is confirmed by enabling verbose logging (log level = 1 auth:10 in smb.conf).

In the code, I've found that in source/libsmb/ntlm_check.c, in ntlm_password_check at line 291, the authentication fails for 2.0g, but succeeds for 2.0n:

                     DEBUG(4,("ntlm_password_check: Checking NTLMv2 password with domain [%s]\n", client_domain));
                        if (smb_pwd_check_ntlmv2( nt_response, 
                                                  nt_pw, challenge, 
                                                  client_username, 
                                                  client_domain,
                                                  False,
                                                  user_sess_key)) {
                                return NT_STATUS_OK;
                        }

Since 2.0n and 2.0g both run the same version of samba with the same patches, I suspect that this is an endianness issue in samba (2.0g runs on big endian, while 2.0n is little endian).

Some more investigation since I started typing this ticket shows that Samba is compiled without WORDS_BIGENDIAN defined, regardless of the target. This breaks UCS2 to native character conversions, which in turn break the lowercase-uppercase mapping tables.

It also seems that just defining this variable isn't enough, the actual generation of uppercase tables in load_case_tables in source/lib/util_unistr.c is also broken. If I fix both, I can actually log in using smbclient again :-D

Since I've now diagnosed this bug properly, including a fix in 2.3.7.1 seems like a good idea, though that does require some extra proper testing.

Attachments (0)

Change History (6)

comment:1 Changed 6 years ago by matthijs

  • Status changed from new to confirmed

It turns out that just properly setting endianness _is_ enough after all, in my previous attempts I probably broken something with earlier debug changes I forgot about. Using a clean samba3 and setting WORDS_BIGENDIAN turned out to fix the problem as well.

comment:2 Changed 6 years ago by matthijs

  • Resolution set to fixed
  • Status changed from confirmed to closed

(In [2342]) samba3: Properly set endianness 2.0g

Apparently before Samba was always compiled for little-endian architectures. Samba uses htons() and friends for its network protocol and doesn't care much for endianness otherwise, except when dealing with UCS2 strings. In particular, the uppercasing/lowercasing of strings wouldn't work properly on big endian systems (2.0g).

The most visible effect of this was that NTLMv2 authentication didn't work. Since Windows Vista and upwards default to NTMLv2, all passwords would be rejected coming from those platforms. Also, recent Linux versions seem to use NTLMv2 by default. The NTLMv1 authentication apparently didn't use this UCS2 functions, so connecting from Windows XP and below was unaffected.

Closes: #1325

comment:3 Changed 6 years ago by matthijs

(In [2343]) Backport r2342: samba3: Properly set endianness 2.0g

Apparently before Samba was always compiled for little-endian architectures. Samba uses htons() and friends for its network protocol and doesn't care much for endianness otherwise, except when dealing with UCS2 strings. In particular, the uppercasing/lowercasing of strings wouldn't work properly on big endian systems (2.0g).

The most visible effect of this was that NTLMv2 authentication didn't work. Since Windows Vista and upwards default to NTMLv2, all passwords would be rejected coming from those platforms. Also, recent Linux versions seem to use NTLMv2 by default. The NTLMv1 authentication apparently didn't use this UCS2 functions, so connecting from Windows XP and below was unaffected.

References: #1325

comment:4 Changed 6 years ago by matthijs

(In [2344]) samba3: Really properly set endianness

In r2342, a patch was added to tell Samba about the big-endianness of 2.0g. However, it used some constants defined by libc, without including the proper header file. Because both of them were undefined, the #if that compared them would always be true, causing samba to always think the system was big endian (which broken 2.0n again...).

This adds the proper include so both big and little endian now work.

References: #1325

comment:5 Changed 6 years ago by matthijs

(In [2345]) Backport r2344: samba3: Really properly set endianness

In r2342, a patch was added to tell Samba about the big-endianness of 2.0g. However, it used some constants defined by libc, without including the proper header file. Because both of them were undefined, the #if that compared them would always be true, causing samba to always think the system was big endian (which broken 2.0n again...).

This adds the proper include so both big and little endian now work.

References: #1325

comment:6 Changed 5 years ago by matthijs

Turns out the same problem also caused #1247.

Add Comment

Modify Ticket

Action
as closed The ticket will remain with no owner.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.