Red Hat Bugzilla – Bug 841314
pcp: malicious client can stop all pmcd server activity
Last modified: 2012-08-20 00:05:25 EDT
The pduread function in libpcp performs a select locally, waiting for more client data. A malicious client can send individual bytes one by one, to avoid the timeout, and monopolize the pmcd server this way. No authentication is required.
As a stop-gap measure, a low overall timeout for the whole PDU should be enforced, and not just a timeout for each individual recv call. A real fix requires a proper event-driven style, that is, all I/O has to be performed in the main event loop, and the I/O routines have to be transformed to continuation-passing style.
Created attachment 602593 [details]
Resolve an event-driven programming flaw in pmcd
Attached is Ken McDonells fix for this. I was a little confused by 841706 which I think is another bug for the same issue, and attached it there late last week.
Here it is again anyway.
(In reply to comment #2)
> Created attachment 602593 [details]
> Resolve an event-driven programming flaw in pmcd
> Attached is Ken McDonells fix for this.
I think dead_hand.tv_usec needs to be adjusted in the if branch, so that it does not exceed 1000000. The comparison needs to be >=, not >.
dead_hand.tv_sec += wait.tv_sec;
dead_hand.tv_usec += wait.tv_usec;
if (dead_hand.tv_usec > 1000000)
Perhaps a comment should be added that this is just a stop-gap measure and that the real fix is more involved.
Created attachment 602904 [details]
Updated version of pmcd event-driven programming flaw patch
Incorporate Florian's review comments.
This issue has been addressed in pcp-3.6.5
This issue was addressed in Fedora and EPEL via the following security updates: