Re: 答复 : about CVE-2020-14367

On Mon, Jun 06, 2022 at 11:18:58AM +0000, chengyechun wrote:
> I understand that modifying the chronyd.pid file requires the root permission, whereas in CVE-2020-14367, only creating smylinks does not require a higher permission.

The pidfile is in a directory where the chrony user has write
permissions. If the pidfile is owned by root, the chrony user cannot
modify it directly, but it can replace it with a new file or symlink.

If the chrony user is compromised, it's game over for chronyd. Denial
of service cannot be prevented.

CVE-2020-14367 was about chronyd following a symlink when writing
the pidfile, before it dropped root privileges. It allowed the chrony
user to write a PID to a file where it didn't have permissions to
write, assuming the directory containing the pidfile already existed
and the service wasn't started yet (e.g. when the service was being
restarted).

> int  check_run(char *proname)
> {
>         FILE            *fp = NULL;
>         char            command[150];
>         char            buf[300];
>         int             count = 3;
> 
>         snprintf(command, sizeof(command), "ps -ef | grep -w %s | wc -l ", proname);
>     
>         fp=popen(command, "r");

Calling ps might be portable, but probably wouldn't be acceptable here
as a good solution.

This would not detect chronyd running under a different name. It would
be susceptible to DoS attacks as it does not check the process owner
(any user could fail the check by running something called chronyd).
Expecting 3 matched lines from grep would be unreliable as ps might
not see the newly started grep process yet.

-- 
Miroslav Lichvar


-- 
To unsubscribe email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org 
with "unsubscribe" in the subject.
For help email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org 
with "help" in the subject.
Trouble?  Email [email protected]