Debian-LTS has issued an advisory on May 10:
The issue is fixed upstream in 1.6.
Pushed in updates testing.
A new version of libntlm.
It fixes CVE-2019-17455
Updated packages in core/updates_testing:
Updated libntlm packages fix security vulnerability:
It was discovered that libntlm through 1.5 relies on a fixed buffer size for
tSmbNtlmAuthRequest, tSmbNtlmAuthChallenge, and tSmbNtlmAuthResponse read and
write operations, as demonstrated by a stack-based buffer over-read in
buildSmbNtlmAuthRequest in smbutil.c for a crafted NTLM request
MGA7-64 Plasma on Lenovo B50
No installation issues.
lib64ntlm0 announces itself in MCC as "A library for authenticating with Microsoft NTLM challenge-response, derived from Samba sources."
but when I
# urpmq --whatrequires lib64ntlm0
and gkrellm says "GKrellM charts SMP CPU, load, Disk, and all active net interfaces automatically. "
So, I'll give it a try when accessing my Samba shares from my desktop PC.
To be continued......
Installed gkrellm, run it, then use MCC trying to mount the SMB-shares in MCC. I can define the mout points, but the actual mounting fails. That's not my first worry now - the smb-shares work OK from a Win10.
Checking the trace, found instance of
openat(AT_FDCWD, "/lib64/libntlm.so.0", O_RDONLY|O_CLOEXEC) = 3
but according MCC, this package provides /usr/lib64/libntlm.so.0 which is not the same???? Or is it?????
/lib64 is a symlink to /usr/lib64 since Mageia 2.
Of course !!! Stupid me.
OK then for me.
Validating. Better advisory in Comment 2.
An update for this issue has been pushed to the Mageia Updates repository.