CCPM connections are accepted from users that don't advertise CCPM support
Bug #1682798 reported by
maksis
This bug affects 2 people
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| AirDC++ |
New
|
Undecided
|
Unassigned | ||
| DC++ |
Confirmed
|
Medium
|
Unassigned | ||
Bug Description
This can be used by spam bots and other malicious clients to randomly establish CCPM connections in hubs that have disabled the CCPM feature.
Revision history for this message
| eMTee (realprogger) wrote | #1 |
| Changed in dcplusplus: | |
| status: | New → Confirmed |
| importance: | Undecided → Medium |
To post a comment you must log in.
<eMTee> A missing safeguard but it means here we rely on hubs to distribute the CCPM flag correctly to both sides and according to a comment in AirDC++'s source, some hubs don't do this. Also hubs can remove this feature bit to maliciously force users to unencrypted chat through the hub. Question is here what's best to do, stick to the protocol, accept the hubs' ability to change the advertised features as they wish (which is the common practice on other protocol elements) or leave as is and ignore the missing feature flag for safety reasons.
<cologic> It's an intersting question, yeah. Because it's ultimately the same C-C mechanism as file transfers, at some point if DC++ or other clients decided to push the issue, hubs would find it hard to enforce this downgrade attack you describe.
The status quo seems okay, I guess. Gating it on the CCPM support would give hubs more control than they have now, a material loss for that feature, without necessarily gaining much. Specifically when (hubs disable CCPM) and (hubs filter spam), it can provide a nicer experience, but I don't know how worthwhile it is to cater to that. I also just don't have much feel for largeish public hubs, though. Maybe it's a real problem, worth the tradeoff.
For the (hubs disable CCPM) and (hubs don't usefully filter spam) scenario it's a pure loss. And for the (hubs don't disable CCPM) cases, it's a no-op.
<eMTee> AirDC++ has, but commented out a code checking for the CCPM flag to be present and my question came from a comment there weighing this situation. So they (the mostly used DC client), as currently the state of their side of the bug entry reflects, have not applied any fix.
Maybe it's worth to give the freedom of the decision to the user then and add an opt-out per hub setting for automatically accepting incoming CCPM connections so on problematic hubs only the user can initiate CCPM towards those whom it wishes to talk securely to.
<cologic> Yeah, I think your proposal about letting users choose is ideal, and absent that, I'm okay with the status quo, regarding requiring CCPM supports