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

Fix two signal races in sshd pre-auth #289

Closed
wants to merge 2 commits into from

Conversation

HerrSpace
Copy link

@HerrSpace HerrSpace commented Nov 12, 2021

grace_alarm_handler is used as a SIGALRM handler in sshd. It will kill
pmonitor->m_pid, which is meant to be a child of a fork done by sshd,
and then exit.

The first signal race could have caused the SIGALRM handler to be
called before we save the pid from the fork in pmonitor->m_pid. In this
case we would not have killed our child before exiting.

The second signal race could have caused the SIGALRM handler to be
called while waiting for a blocking waitpid or right after that, before
clearing pmonitor->m_pid. In this case we would potentially have killed
a foreign process, that reused this pid.

Shoutout to @c3h2-ctf and @stoeckmann

grace_alarm_handler is used as a SIGALRM handler in sshd. It will kill
pmonitor->m_pid, which is meant to be a child of a fork done by sshd,
and then exit.

The signal race could have caused the SIGALRM handler to be called
before we save the pid from the fork in pmonitor->m_pid. In this case
we would not have killed our child before exiting.
grace_alarm_handler is used as a SIGALRM handler in sshd. It will kill
pmonitor->m_pid, which is meant to be a child of a fork done by sshd,
and then exit.

The signal race could have caused the SIGALRM handler to be called
while waiting for a blocking waitpid or right after that, before
clearing pmonitor->m_pid. In this case we would potentially have killed
a foreign process, that reused this pid.
@HerrSpace
Copy link
Author

Gentle reminder regarding this PR. Would somebody be up to review this? :) CC @daztucker as you have looked at PRs in the past here.

@daztucker
Copy link
Contributor

I spent some time looking at these, and while I agree your patches fix the problem, I think a better way to fix it is to remove the monitor pid reference from the handler entirely. Its function is covered by the kill(0, ...), which was added later, since it's in the same process group, and now that privsep is mandatory we no longer have to handle the !privsep case.

@daztucker
Copy link
Contributor

The race should be fixed by commit 4e62c13. Thanks for the analysis.

@daztucker daztucker closed this Feb 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants