versat / cntlm Goto Github PK

Hello is there a

1. Having detailed logging such as suburl ?
2. Can we add custom headers to outgoing requests such as no-cache etc.

if not can we behave this issue as a Feature Request?

Hi everyone

Environment :

• Windows 10
• Cntlm (master build branch with cygwin 64)
• NodeJS v20.11.1 & v16.14.0
• NPM 10.2.4 & 8.19.4

Crash :

It seems that CNTLM crashes when I install a large project with NPM install.
Here are the logs I get (repeated several times) with an NPM on Windows:

• cntlm: PID 218: write() failed with error 9: Bad file descriptor
• cntlm: PID 218: No proxy on the list works. You lose.
• cntlm: PID 218: Proxy connect failed, will try <ourProxy>:3129
• cntlm: PID 218: no buffer space available

After trying the same procedure, but with CNTLM installed on Linux, it works without crashing the cntlm proxy (by installing the NPM project on Windows and setting the proxy parameter to the Linux server).
However, I get this message:

• "Too many files open"

It seems that the crash on Windows comes from Cygwin, but I'm not 100% sure. If so, is there a workaround ?

Thank you

In the default cntlm.conf, there are comments like:

# NOTE: all values are parsed literally, do NOT escape spaces,
# do not quote. Use 0600 perms if you use plaintext password.

Despite that it is true there is no need to use URL escape characters (e.g., %40 for @), it is however needed to double quote some special characters like #, ;, , which is mentioned clearly in cntlm's man page.

Proxy account password. As with any other option, the value (password) can be enclosed in double quotes (") in case it contains special characters like spaces, pound signs, etc.

Configuration file is basically an INI file, except there are no "=" between keys and values. It comprises of whitespace delimited keyword and value pairs. Apart from that, there are sections as well, they have the usual "[section_name]" syntax. Comment begins with a hash "#" or a semicolon ";" and can be anywhere in the file. Everything after the mark up until EOL is a comment. Values can contain any characters, including whitespace. You can use double quotes around the value to set a string containing special characters like spaces, pound signs, etc. No escape sequences are allowed in quoted strings.

Therefore when password contains some special characters like #, ;, it will ignore the subsequent characters afterwards. So Password XXX#YYY will be treated as Password XXX; and the correct configuration is Password "XXX#YYY".

Detailed background is here: jetty/jetty.project#6483
In summary CNTLM slaps Connection: close when CONNECT method is successful. This seems wrong and creates a problem with TLS connections for clients that respect this header in this scenario.

Recently I stumbled upon an unusual use case, where there is a remote server that accepts plain http connections (not https) and requires NTLM authentication. Cntlm tries and authenticate but hangs the thread (mainly because it should send the request body twice, but the second time it is not available any more).

By removing this code block...

...it works because the authentication is delegated to the client.

This use case is very rare because usually connections are in https and cntlm simply tunnels them.

In my opinion this behaviour is out of scope because cntlm should deal with authentications against proxies and not against target servers.

I propose to remove this code block completely. (I guess nobody has ever tested this piece of code).

Hi,

I just tested your version of cntlm and when the first requests arrives, the process just stops. Are you using this on Windows?

Thanks
Dirk

When using pacparser version without configuring a pacfile, a lot of pacparser.c: pacparser_find_proxy: Pac parser is not initialized. messages are logged to stdout/stderr.

Pac file defined with PacFile attribute fails when it is longer than 50 chars.
It looks like path file is truncated when read from config file.

according to https://winprotocoldoc.blob.core.windows.net/productionwindowsarchives/MS-NLMP/%5bMS-NLMP%5d.pdf page 59

Define NTOWFv2(Passwd, User, UserDom) as HMAC_MD5(
MD4(UNICODE(Passwd)), UNICODE(ConcatenationOf( Uppercase(User),
UserDom ) ) )
EndDefine
Define LMOWFv2(Passwd, User, UserDom) as NTOWFv2(Passwd, User,
UserDom)
EndDefine
...

the userDom has to be used for hashing the password, but cntlm instead uses the target, which should have the value of userDom, because cntlm is requesting the server to add the target information(NTLMSSP_REQUEST_TARGET flag), but there are cases e.g. McAffee Webgateway, where the request for target, is ignored (although this is a violation of the protocol ).

	if (creds->hashntlm2 && !tblen) {
		return 0;
	}

	if (creds->hashntlm2) {
		ntlm2_calc_resp(&nthash, &ntlen, &lmhash, &lmlen, creds->passntlm2, challenge, tbofs, tblen);
	}

by changing cntlm to use userDom instead of target, we would be compliant with the protocol spec, and also to able handle edge cases as mentioned

something like:

	if (creds->hashntlm2 && !userDomofs) {
		return 0;
	}

	if (creds->hashntlm2) {
		ntlm2_calc_resp(&nthash, &ntlen, &lmhash, &lmlen, creds->passntlm2, challenge, userDomofs, userDomlen);
	}

Using the "feature" I submitted (static linking) in #16 I'm encountering a failure that seems to be associated with joining a thread after a request is complete. I'm entering this just for awareness and as a reminder for me to look further into it, I doubt you want to be supporting/debugging ppc64le & statically linked CNTLM- if you even have access to a ppc64le Linux machine :)

The request finishes successfully (the client gets the results) but then cntlm goes down with a SIGSEGV:

Connection                     => close
Content-Length                 => 93
Proxy-Authenticate             => NTLM
Sending headers (5)...
Body included. Length: 93
data_send: read 93 of 93 / 93 of 93 (errno = ok)
data_send: wrote 93 of 93
Body sent.
PROXY CLOSING CONNECTION
forward_request: palive=0, authok=0, ntlm=0, closed=1

Thread finished.
proxy_thread: request rc = 0xffffffffffffffff
Joined thread 70366707252944; rc: 0

In gdb, I'm seeing this, it appears to be a NULL pointer dereference, likely associated wioth the -1 return from proxy_thread():

Thread finished.
proxy_thread: request rc = 0xffffffffffffffff
[LWP 16317 exited]
Joined thread 70367536021200; rc: 0

Thread 1 "cntlm" received signal SIGSEGV, Segmentation fault.
0x0000000010002b08 in main ()
(gdb) 
(gdb) x/4i $pc
=> 0x10002b08 <main+10568>:	lxvd2x  vs0,0,r9
   0x10002b0c <main+10572>:	stxvd2x vs0,r1,r10
   0x10002b10 <main+10576>:	bl      0x1013408c <select+8>
   0x10002b14 <main+10580>:	nop
(gdb) i r vs0 r9
vs0            {uint128 = 0x00000000000000000000000000000000, v2_double = {0x0, 0x0}, v4_float = {0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, 
  v16_int8 = {0x0 <repeats 16 times>}}
r9             0x0	0
(gdb) bt
#0  0x0000000010002b08 in main ()
(gdb) 

I'll look into this more as I get a chance. If you prefer, you can close the issue here and I can open it on my fork

On macOS 12 (Monterey) build fails:

$ ./configure
$ make
...
socket.c:112:4: error: use of undeclared identifier 'u_short'; did you mean 'short'?
                        u_short port = 0;
                        ^~~~~~~
                        short
...

To complete build I had to add a couple of compilation flags to Makefile:
CFLAGS += -D_DARWIN_C_SOURCE -D_FORTIFY_SOURCE=0

Is it possible to fix it in configure script?

I'm testing the Windows version of cntlm built with Cygwin.
It works, but each "pthread_join()" fails with the following log:

Serious error during pthread_join: 22

22 corresponds to EINVAL error.
I built it with Cygwin version 3.3.4 with the default configuration (no kerberos and no pacparser).
This is reproducible by running cntlm from a cmd terminal with -f parameter to keep it in foreground.

The interesting thing is that this doesn't happen when launched from the Cygwin's shell. In this case pthread_join() doesn't fail.
Can this be related to issue #18?

In case the user has disconnected from the corporate network and is using the device on the pure Internet

when the cntlm is running in threading mode, and accessing the https website.
the cntlm will crash with memory fault.

when the cntlm is running in serial mode, and accessing the https website, it is running ok,

this only happen after there is change of proxy.
this is sparc solaris 11,
i run ./configure, gmake to make binary.

THank you

I'm running into a situation where a lot of consecutive requests are causing cntlm to hang. The output ends with a huge amount of messages like:

[Thread 0x7ffff465b700 (LWP 46761) exited]
Joined thread 140736274474752; rc: 0
Joined thread 140736277956352; rc: 0
Joined thread 140736269600512; rc: 0
Joined thread 140737288541952; rc: 0
Joined thread 140737288333056; rc: 0
Joined thread 140737291048704; rc: 0
Joined thread 140737293137664; rc: 0
Joined thread 140736271759104; rc: 0
Joined thread 140736270853888; rc: 0
Joined thread 140737293764352; rc: 0
Joined thread 140736274753280; rc: 0
Joined thread 140737299195648; rc: 0
Joined thread 140737293694720; rc: 0
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff4738700 (LWP 46762) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7fffb75a3700 (LWP 46763) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff468e700 (LWP 46764) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff45b1700 (LWP 46765) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7fffb7e12700 (LWP 46767) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7fffb765e700 (LWP 46766) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7fffb761a700 (LWP 46769) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff43c4700 (LWP 46768) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7fffb75e7700 (LWP 46770) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff4072700 (LWP 46771) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff4eca700 (LWP 46772) exited]
Joined thread 140737294599936; rc: 0
Joined thread 140736269530880; rc: 0
Joined thread 140737293903616; rc: 0
Joined thread 140737292998400; rc: 0
Joined thread 140736278374144; rc: 0
Joined thread 140736270296832; rc: 0
Joined thread 140736270018304; rc: 0
Joined thread 140737290979072; rc: 0
Joined thread 140736269809408; rc: 0
Joined thread 140737287497472; rc: 0
Joined thread 140737302537984; rc: 0
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff4e53700 (LWP 46778) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff4c66700 (LWP 46777) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff4a79700 (LWP 46776) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff4bcd700 (LWP 46779) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff7f3c700 (LWP 46780) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff4b89700 (LWP 46773) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff4c11700 (LWP 46775) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff4061700 (LWP 46782) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff4d10700 (LWP 46781) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff4c99700 (LWP 46784) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff476b700 (LWP 46785) exited]
Joined thread 140737302050560; rc: 0
Joined thread 140737300031232; rc: 0
Joined thread 140737298011904; rc: 0
Joined thread 140737299404544; rc: 0
Joined thread 140737353336576; rc: 0
Joined thread 140737299126016; rc: 0
Joined thread 140737299683072; rc: 0
Joined thread 140737287427840; rc: 0
Joined thread 140737300727552; rc: 0
Joined thread 140737300240128; rc: 0
Joined thread 140737294808832; rc: 0
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff4d76700 (LWP 46786) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff423d700 (LWP 46793) exited]
proxy_thread: request rc = 0xffffffffffffffff
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff4dcb700 (LWP 46794) exited]
[Thread 0x7ffff4f52700 (LWP 46795) exited]
proxy_thread: request rc = 0xffffffffffffffff
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff4749700 (LWP 46797) exited]
[Thread 0x7ffff46c1700 (LWP 46796) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff4d21700 (LWP 46798) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff4e20700 (LWP 46799) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff41c6700 (LWP 46800) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff4e42700 (LWP 46802) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff4cdd700 (LWP 46801) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff4d98700 (LWP 46787) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff4ffc700 (LWP 46803) exited]
Joined thread 140737301145344; rc: 0
Joined thread 140737289377536; rc: 0
Joined thread 140737301493504; rc: 0
Joined thread 140737303095040; rc: 0
Joined thread 140737294669568; rc: 0
Joined thread 140737294112512; rc: 0
Joined thread 140737300797184; rc: 0
Joined thread 140737301841664; rc: 0
Joined thread 140737288890112; rc: 0
Joined thread 140737301980928; rc: 0
Joined thread 140737300518656; rc: 0
Joined thread 140737301284608; rc: 0
Joined thread 140737303791360; rc: 0
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff4efd700 (LWP 46805) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff4edb700 (LWP 46806) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff4eec700 (LWP 46807) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff523e700 (LWP 46810) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff4da9700 (LWP 46808) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff4f74700 (LWP 46811) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff53f8700 (LWP 46812) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff4d54700 (LWP 46814) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff4cff700 (LWP 46815) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff7f4d700 (LWP 46816) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff420a700 (LWP 46804) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff4094700 (LWP 46817) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff402e700 (LWP 46818) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff5150700 (LWP 46819) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7ffff500d700 (LWP 46820) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7fffb7807700 (LWP 46821) exited]
proxy_thread: request rc = 0xffffffffffffffff
[Thread 0x7fffb75c5700 (LWP 46822) exited]
Joined thread 140737302746880; rc: 0
Joined thread 140737302607616; rc: 0
Joined thread 140737302677248; rc: 0
Joined thread 140737306158848; rc: 0
Joined thread 140737301354240; rc: 0
Joined thread 140737303234304; rc: 0
Joined thread 140737307969280; rc: 0
Joined thread 140737301006080; rc: 0
Joined thread 140737300657920; rc: 0
Joined thread 140737353406208; rc: 0
Joined thread 140737289168640; rc: 0
Joined thread 140737287636736; rc: 0
Joined thread 140737287218944; rc: 0
Joined thread 140737305184000; rc: 0
Joined thread 140737303860992; rc: 0
Joined thread 140736272037632; rc: 0
Joined thread 140736269670144; rc: 0

I suspect something is going wrong with the thread counting or the mutex.

When server replies with a:

HTTP/1.1 401 Unauthorized
Connection: close
Content-Length: 1234

Bla bla you were not authorized to view this resource. Please authenticate.

• direct_request() closes then reopens the connection (close(sd); sd = host_connect(…);)
• then discards the response body with http_body_drop() (called from www_authenticate())
• which waits indefinetely for the 1234 bytes on the new (thus empty) socket

It would be helpful to have asterisks echoed during password entry as I use a yubikey for the 2nd half of my password at work and with no feedback, I cannot be sure that a password was entered or that it is the password and not the FIDO OTP.

Hi

We are facing a problem that we can't connect to a domain because it is cut off after 50 characters.
While analyzing we found that in main.c L791 the hostname is copied with the parameter MINIBUF_SIZE, although
our domain length is at 59 saved in the variable c some lines above. Thus the domain is cut off, which can be seen when switching -v for cntlm.

If I replace MINIBUF_SIZE by BUFSIZE at

it works

As I don't understand the meaning of the MINIBUF_SIZE and why there is a restriction, I can't fix this issue.
Could you fix it or explain why there is a hard cut with 50 characters.
The issue happens with a socks connection between program and cntlm.

Thanks in advance
Florian

Hi All,

I see that the repo is being regularly built, including for OSX.
Are the binaries created stored anywhere? I'd need windows, generic modern linux, and OSX.

I've been using px (python based), but with cntlm getting some great updates, including sspi, it becomes an attractive solution to our corporate networking woes... especially as px is now a folder full of deps, whereas cntlm still has minimal deps.

Simon

Running:

$ cntlm -a gss -c ./cntlm.conf

starts cntlm in background mode (no -f flag) and with kerberos auth.

When receiving the very first request cntlm process crashes immediately without emitting any syslog message or trace.

NB. Conversely NTLM auth works as expected in background mode

situation:
I tried to build cntlm.exe under linux ubuntu OS. what I did:

• I have installed all needed packages to build cntlm
• I have copied all needed libraries of cygwin from windows OS to ubuntu OS (e.g. cyggcc_s-seh-1.dll, cygrunsrv.exe, cygstdc++-6.dll, cygwin1.dll)
• run ./configure && make && make win
• I got an general error strip: cntlm.exe: No such file

question:
is there any way to build cntlm.exe under ubuntu OS? e.g. using minGW-w64 on Linux Ubuntu OS

Hello. First of all, thank you for maintaining this wonderful project. cntlm is awesome.

It was recently blocked at my workplace because it stores (admittedly hashed) sensitive credentials in a text file. Would it be possible to integrate cntlm with osx keychain? How much of a lift do you think it would be?

Thanks!

https://github.com/versat/cntlm/blob/master/http.c#L705

The use of strlen() here means only the first token is cleared since pos, and dom alias buf and are used to write nulls over the delimiters.