[Security] Document StatelessProcessGroup security concerns #17591
Conversation
|
👋 Hi! Thank you for contributing to the vLLM project. 💬 Join our developer Slack at https://slack.vllm.ai to discuss your PR in #pr-reviews, coordinate on features in #feat- channels, or join special interest groups in #sig- channels. Just a reminder: PRs would not trigger full CI run by default. Instead, it would only run Once the PR is approved and ready to go, your PR reviewer(s) can run CI to test the changes comprehensively before merging. To run CI, PR reviewers can either: Add 🚀 |
russellb
force-pushed
the
statelessprocessgroup-security
branch
from
f320c43 to
3e3ac95
Compare
A recent PR, vllm-project#15988, improved StatelessProcessGroup to ensure the torch.distributed TCPStore uses the specified IP address unless of binding to all interfaces. Upon closer inspection, this is quite important, as the way vllm is using this TCPStore includes pickled data, so malicious access to the TCPStore would allow remote code execution on a vllm host. Update some places throughout the code base to reflect the importance of specifying a secured IP addres for use with this interface. Finally, fix a couple places in tests to explicitly use localhost instead of the IP we find that's (probably) the one used for the host's default route. Otherwise, a host running these tests is briefly vulnerable on the IP address chosen. Signed-off-by: Russell Bryant <[email protected]>
russellb
force-pushed
the
statelessprocessgroup-security
branch
from
3e3ac95 to
ba86dd6
Compare
A recent PR, #15988, improved StatelessProcessGroup to ensure the
torch.distributed TCPStore uses the specified IP address unless of
binding to all interfaces. Upon closer inspection, this is quite
important, as the way vllm is using this TCPStore includes pickled data,
so malicious access to the TCPStore would allow remote code execution on
a vllm host.
Update some places throughout the code base to reflect the importance of
specifying a secured IP addres for use with this interface.
Finally, fix a couple places in tests to explicitly use localhost
instead of the IP we find that's (probably) the one used for the host's
default route. Otherwise, a host running these tests is briefly
vulnerable on the IP address chosen.
Signed-off-by: Russell Bryant [email protected]