[ Impact ]
A segmentation fault occurs when a user tries to to obtain a pair of NTLM hashes in plain text using smbencrypt.
The reason behind this is that the NTLM protocol uses MD4 and MD5 algorithms that have been declared cryptographically broken (also sha1) and moved to legacy providers since openssl3 [1].
Therefore, to use those algorithms, smbscrypt has to be able to load them: this imported upstream fixup does that.
[ Test Plan ]
#0.Prepare a Jammy VM or Container. i.e:
# lxc launch ubuntu-daily:jammy Jfreeradius
# lxc shell Jfreeradius
## Bad Case
#1. Install freeradius-utils
# apt update && apt upgrade -y
# apt install -y freeradius-utils
#2.Raise the issue by running
# smbencrypt test
root@Jfreeradius:~# smbencrypt test
LM Hash NT Hash
-------------------------------- --------------------------------
Segmentation fault (core dumped)
## Good case (after upgrading to proposed package in this SRU)
# apt update && apt upgrade -y freeradius-utils
# smbencrypt test
root@Jfreeradius:~# smbencrypt test
LM Hash NT Hash
-------------------------------- --------------------------------
01FC5A6BE7BC6929AAD3B435B51404EE 0CB6948805F797BF2A82807973B89537
[ Where problems could occur ]
The fix comes from upstream and is already part of the versions present in Lunar, Mantic and Noble: we can then consider that it is well-tested and supported.
Bringing a non-recommended algorithm is never good from a security point of view, with exceptions: this is one of those exceptions because the NTML protocol is based on those algorithms, and this tool for the freeRADIUS client is specifically for that, without further ado. The community is aware of this, and why SMB still uses this protocol, I think, is interesting but out of the scope of this SRU.
Also, and to finish, smbencrypt is a small tool to help LDAP admins that is not called by anything else within the freeRADIUS suite, so it is almost non-existent the risk of breaking something (except ad-hoc scripts that use it, but that must be broken at the time of writing this due to this bug).
[ Other Info ]
The same package was fixed in the same way when Jammy was still our development release [2].
[1] https://www.openssl.org/docs/man3.0/man7/migration_guide.html#Legacy-Algorithms
[2] https://bugs.launchpad.net/ubuntu/+source/freeradius/+bug/1962046
[Original Report]
------------------------------------------------------------
This is due to this bug:
https://github.com/FreeRADIUS/freeradius-server/issues/4539
Please update the packages if possible.
Thank you.
ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: freeradius-utils 3.0.26~dfsg~git20220223.1.00ed0241fa-0ubuntu3.1
ProcVersionSignature: Ubuntu 5.15.0-88.98-generic 5.15.126
Uname: Linux 5.15.0-88-generic x86_64
ApportVersion: 2.20.11-0ubuntu82.5
Architecture: amd64
CasperMD5CheckResult: pass
Date: Mon Nov 6 11:25:39 2023
InstallationDate: Installed on 2023-01-06 (303 days ago)
InstallationMedia: Ubuntu-Server 22.04.1 LTS "Jammy Jellyfish" - Release amd64 (20220809)
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: freeradius
UpgradeStatus: No upgrade log present (probably fresh install)
Thanks for taking the time to report this bug and trying to make Ubuntu better.
I was able to reproduce the bug in a Jammy container by just installing freeradius-utils and running 'smbencrypt test'.
After taking a look at the bug, this seems to be the upstream patch to fix this issue:
https:/