Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

su to radiusd user/group when rotating logs #2666

Merged
merged 1 commit into from May 7, 2019

Conversation

Projects
None yet
4 participants
@cipherboy
Copy link
Contributor

commented May 7, 2019

The su directive to logrotate ensures that log rotation happens under the
owner of the logs. Otherwise, logrotate runs as root:root, potentially
enabling privilege escalation if a RCE is discovered against the
FreeRADIUS daemon.

This attack avenue seems quite unlikely to me. The other alternative is making the /var/log/radiusd directory owned by root. It seems like the logrotate method is better hygiene though. Thoughts?

Signed-off-by: Alexander Scheel <ascheel@redhat.com>

su to radiusd user/group when rotating logs
The su directive to logrotate ensures that log rotation happens under the
owner of the logs. Otherwise, logrotate runs as root:root, potentially
enabling privilege escalation if a RCE is discovered against the
FreeRADIUS daemon.

Signed-off-by: Alexander Scheel <ascheel@redhat.com>

@arr2036 arr2036 merged commit 1f23377 into FreeRADIUS:v3.0.x May 7, 2019

1 check was pending

continuous-integration/travis-ci/pr The Travis CI build is in progress
Details
@arr2036

This comment has been minimized.

Copy link
Member

commented May 7, 2019

Could you do a similar PR for master

@cipherboy

This comment has been minimized.

Copy link
Contributor Author

commented May 7, 2019

Happy to, will do. Thanks!

@ret2libc

This comment has been minimized.

Copy link

commented May 23, 2019

CVE-2019-10143 has been assigned to this issue.

@alandekok

This comment has been minimized.

Copy link
Member

commented May 23, 2019

@ret2libc What security issue mandates a CVE? I'm not sure there's a need for a CVE which has no current way to exploit it. Are we issuing CVEs now for potential issues?

@ret2libc

This comment has been minimized.

Copy link

commented May 24, 2019

@alandekok we are aware of a way to exploit this, though it requires the attacker to already have "high privileges" (that is, he needs to have access to the radiusd user)

@alandekok

This comment has been minimized.

Copy link
Member

commented May 24, 2019

@ret2libc " we are aware of a way to exploit this"

Uh... any thought that you might tell us about this? The email address security@freeradius.org has existed for ~20 years, and is available on the public web page. Why did you not look there?

Is it common RedHat security practice to file for a CVE, and then never tell the authors about it?

On top of that, I'm skeptical of "security" issues which require already privileged access. If the "attacker" has access to the radiusd user, then he can run the RADIUS server, and authenticate anyone he wants. That's a huge security problem, too.

So maybe you need to issue another CVE saying "someone running as radiusd can run the RADIUS server"!

I'm more than a bit surprised at this process. It's utterly bizarre to not inform the authors of an issue, and file for a CVE without giving the authors any prior notification.

We will be issuing a PGP signed vendor statement about this process, along with our opinion of the validity of the CVE.

Do you have any feedback which mitigates the disastrous process you've used here?

@ret2libc

This comment has been minimized.

Copy link

commented May 28, 2019

Uh... any thought that you might tell us about this? The email address
security@freeradius.org has existed for ~20 years, and is available on the
public web page. Why did you not look there?

Sorry for not using your security email first, but the issue was already public
in our bugzilla since May 1st
(https://bugzilla.redhat.com/show_bug.cgi?id=1705143), which, I guess, led
@cipherboy to submit this PR upstream. It was not discovered by Red Hat as far
as I know. Anyway, the comment of the commit clearly explain that the impact is
privilege escalation from radius user to root and given the CVE was assigned
weeks later, after the bug was public and the patch was already acknowledged and
accepted upstream, I did not think an extra email was required.

@ret2libc " we are aware of a way to exploit this"

For "a way to exploit this", you can see the reproducer in the first comment of
https://bugzilla.redhat.com/show_bug.cgi?id=1705143, which confirms the problem
is real.

On top of that, I'm skeptical of "security" issues which require already
privileged access. If the "attacker" has access to the radiusd user, then he
can run the RADIUS server, and authenticate anyone he wants. That's a huge
security problem, too.

As you said, the flaw has limited impact, since it requires the attacker to
already have control of the radiusd user, but it let him escalate his privileges
to root after having compromised the freeradius server. It is true that radiusd
user compromise is already not good, but we still believe that privilege
escalation from radius user to root has a security impact, which deserves a CVE.

Is it common RedHat security practice to file for a CVE, and then never tell
the authors about it?

We do have very careful security response processes in place, but I agree in
this particular instance we made a mistake and we could have handled the issue
better. We will try to work more closely with you from now on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.