The systemd service file for freeradius runs "chown -R" on a directory before it starts: ExecStartPre=-/bin/chown -R radius.radius /run/radiusd That can be exploited by the "radius" user to gain root. After the service has been started once, the radius user can place a hard link to a root-owned file in /run/radiusd. If the service is later restarted, then the "chown -R" command will give away ownership of that root-owned file to the "radius" user. I'm marking this private, but the package is maintainer-needed, so security@ will have to CC someone appropriate to fix it.
Hi, i'm the maintainer of freeradius package. Thanks for the report. I will share this to FreeRadius team soon and I will patch this current version until 3.0.20 is out.
Just for clarification, in this case, a solution is to fix the permissions directly from ebuild and avoid use chown inside freeradius.service?
Just a note: I will wait your feedback for apply patch or other until the embargo is lifted.
(In reply to Geaaru from comment #2) > Just for clarification, in this case, a solution is to fix the permissions > directly from ebuild and avoid use chown inside freeradius.service? Since /run gets wiped on every reboot, creating it in the ebuild won't work sadly. What gets stored in /run/radiusd? If it's only a PID file, then there's probably a smarter solution to this whole problem. For example you might launch the daemon as a "simple" service and let systemd manage the PID file for you. Then the /run/radiusd directory isn't needed at all, problem solved. On the other hand, if there's (for example) a socket stored there and if the radiusd daemon needs to write to it after dropping privileges, then the directory does need to be there, and writable by the "radius" user. In that case, a "tmpfiles.d" entry is the usual way that systemd creates these subdirectories of /run. You can either google for the tmpfiles.d spec, or (probably easier) just look for examples in Gentoo. Don't worry about the embargo, I reported this two years ago =P
Thanks for feedback. In current ebuild IIRC yes is stored pidfile. But the current develop branch of 3.0.x contains my fix for integrate Freeradius with Systemd and to use Notify type. So, probably if systemd integration is enable is not possible start process with "simple" type. In additional, under /run/radius could be used for store socket used for radmin connection (management, etc.). Ok, i will try to speak of this with FreeRadius guys to choice the right path and for use tmpfiles.d. Ah, I just read now that the issue is been created on 2017 :D Thanks Daniele Rondina aka geaaru
Hi, first issue is that now freeradius.service doesn't contain anymore chown with -R option. It's only in old freeradius-3.0.15 that I will drop after release 3.0.20 (i'm waiting upstream bump). Freeradius-3.0.18 use a .service patch: https://github.com/gentoo/gentoo/blob/master/net-dialup/freeradius/files/freeradius-3.0.18-systemd-service.patch and on upstream tree chown is without -R. After this, I speak today with FreeRadius guys and as visible by these commits now chown is not used anymore: - https://github.com/FreeRADIUS/freeradius-server/commit/26e412b0f775d7219364fec3c204ba6e5877ff1a - https://github.com/FreeRADIUS/freeradius-server/commit/b6f8a6fdd456ebfa889b8867317632bd0ac6b887 - https://github.com/FreeRADIUS/freeradius-server/commit/aec8b3e9bbdb67b04fbd3eca8e757e1f114ec613 because it's used User,Group,RuntimeDirectory that fix directly /run/radiusd permissions. So, you could close this issue or wait for drop of v.3.0.15.
Thanks for the fast response! The security team will usually call for an "emergency" stabilization in cases like these, and then will close the bug after the old vulnerable versions have been removed (they have their own process for this stuff). The fix in v3.0.18 looks good to me. Unrelated: I don't run systemd so I can't check, but the documentation for "RuntimeDirectory" at https://www.freedesktop.org/software/systemd/man/systemd.exec.html says that it will change the directory owner/group automatically. So, in v3.0.18, the following line in the ebuild can probably be deleted: systemd_newtmpfilesd "${FILESDIR}"/freeradius.tmpfiles freeradius.conf Again, thanks for helping to get this fixed finally.
Yeah, you're right. We can remove systemd_newtmpfilesd. Ok, I waiting for version 3.0.20 and then I will fix also ebuild of 3.0.18. It's needed a bit of time because FreeRadius guys will release 3.0.20 when integration of TLS 1.3 is done. When I will push PR with fix I will align this thread. Thanks to you for the report.
Unrestricting and reassigning to security@ per bug #705894
unrestricting per bug 705894
(In reply to Geaaru from comment #8) > Yeah, you're right. We can remove systemd_newtmpfilesd. > > Ok, I waiting for version 3.0.20 and then I will fix also ebuild of 3.0.18. > > It's needed a bit of time because FreeRadius guys will release 3.0.20 when > integration of TLS 1.3 is done. > > When I will push PR with fix I will align this thread. > > Thanks to you for the report. Looks like this is fixed now. Is that right? :)
Sorry to all here. I will try to push the fix in the next two/three days. Very few time in the last period for covid problems. I hope to close this issue soon.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=48cd44905411daf0c9914d0df63b387e29e75b10 commit 48cd44905411daf0c9914d0df63b387e29e75b10 Author: Daniele Rondina <geaaru@gmail.com> AuthorDate: 2020-09-18 10:15:27 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2020-10-17 13:19:14 +0000 net-dialup/freeradius: Bump v.3.0.20-r1 Drop unneeded systemd's tmpfiles Package-Manager: Portage-2.3.89, Repoman-2.3.22 Signed-off-by: Daniele Rondina <geaaru@gmail.com> Bug: https://bugs.gentoo.org/630910 Signed-off-by: Joonas Niilola <juippis@gentoo.org> net-dialup/freeradius/files/freeradius.tmpfiles | 1 - .../freeradius/{freeradius-3.0.20.ebuild => freeradius-3.0.20-r1.ebuild} | 1 - 2 files changed, 2 deletions(-)
This issue was resolved and addressed in GLSA 202101-27 at https://security.gentoo.org/glsa/202101-27 by GLSA coordinator Sam James (sam_c).
