Hi -
> > What? No. That CVE was about [...]
>
> This is the summary, from the CVE:
> "Performance Co-Pilot (PCP) before 3.6.5 exports some of the /proc file
> system, which allows attackers to obtain sensitive information such as
> proc/pid/maps and command line arguments".
An informed person does not interpret a CVE solely based on its
summary line, which misses detail, context, severity. (If one did,
one could fault /usr/bin/pminfo the same way.)
> [...] I'll make the needed pmwebd changes this week.
Saw the proposed changes in your git branch. Restricting looks OK as
a default. The local:* stuff should not be marked as deprecated nor
be undocumented: that still has plenty of safe & appropriate use.
> > pmwebd, like pmproxy, lacks detailed outgoing ACL facilities - see
>
> Again, pmproxy does not create (automatically authenticated) unix: or
> local-context connections on behalf of remote clients, so it is not
> exposed to this problem.
An outgoing ACL is required to even contemplate putting pmwebd or
pmproxy onto a hostile network (e.g., to prevent their use as network
scanners), and would subsume the proposed pmwebd "-P" flag.
> > > > When a 1-line bash script can DoS pmcd [...]
> > > What??? Could you please supply that script? - thanks.
> > [...]
>
> You've forgotten to supply the "1-line bash script" ...?
OK, if you need me to spell out "pmcd now only hangs for a few seconds
after a hostile client sends a few bytes of data instead of
indefinitely" in code:
(printf "\x00\x00\x01" ; sleep 5) > /dev/tcp/localhost/44321
But, as I explained, there are multiple design limitations at play;
solving this one will get pmcd only a tiny bit closer to being
deployable directly on a hostile network. (If you're serious about
it, expect to spend months.)
- FChE
|