Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 630910

Summary: <net-dialup/freeradius-3.0.20-r1: root privilege escalation via systemd service file
Product: Gentoo Security Reporter: Michael Orlitzky <mjo>
Component: AuditingAssignee: Gentoo Security <security>
Status: RESOLVED FIXED    
Severity: normal CC: geaaru, sam, security-audit
Priority: Normal Keywords: PullRequest
Version: unspecified   
Hardware: All   
OS: Linux   
See Also: https://github.com/gentoo/gentoo/pull/17587
Whiteboard: C3 [glsa+]
Package list:
Runtime testing required: ---

Description Michael Orlitzky gentoo-dev 2017-09-13 17:38:07 UTC
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.
Comment 1 Geaaru 2019-09-15 19:35:38 UTC
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.
Comment 2 Geaaru 2019-09-15 19:44:08 UTC
Just for clarification, in this case, a solution is to fix the permissions directly from ebuild and avoid use chown inside freeradius.service?
Comment 3 Geaaru 2019-09-15 19:55:21 UTC
Just a note: I will wait your feedback for apply patch or other until the embargo is lifted.
Comment 4 Michael Orlitzky gentoo-dev 2019-09-15 20:01:43 UTC
(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
Comment 5 Geaaru 2019-09-15 20:10:59 UTC
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
Comment 6 Geaaru 2019-09-16 15:01:55 UTC
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.
Comment 7 Michael Orlitzky gentoo-dev 2019-09-16 16:48:31 UTC
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.
Comment 8 Geaaru 2019-09-16 17:01:53 UTC
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.
Comment 9 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2020-04-03 23:16:32 UTC
Unrestricting and reassigning to security@ per bug #705894
Comment 10 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2020-04-03 23:18:06 UTC
unrestricting per bug 705894
Comment 11 Sam James archtester gentoo-dev Security 2020-05-25 14:13:21 UTC
(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? :)
Comment 12 Geaaru 2020-08-31 05:50:20 UTC
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.
Comment 13 Larry the Git Cow gentoo-dev 2020-10-17 13:19:29 UTC
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(-)
Comment 14 GLSAMaker/CVETool Bot gentoo-dev 2021-01-26 00:22:25 UTC
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).