Undisclosed ctcp based DoS vulnerability
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Hardy Backports |
Won't Fix
|
Undecided
|
Unassigned | ||
Jaunty Jackalope Backports |
Won't Fix
|
Undecided
|
Unassigned | ||
Karmic Backports |
Won't Fix
|
Undecided
|
Unassigned | ||
quassel (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Jaunty |
Fix Released
|
Undecided
|
Unassigned | ||
Karmic |
Fix Released
|
Undecided
|
Unassigned | ||
Lucid |
Fix Released
|
Undecided
|
Unassigned | ||
Maverick |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Binary package hint: quassel
The information I have is from one of the upstream developers based on a private vulnerability report they got today.
The ctcp specs allow sending multiple ctcp requests in one irc-message that in return trigger X ctcp replies. If someone sens N msgs all containing X ctcp requets, quassel will respond with N times X ctcp replies (which is correct by the spec), but that triggers quassels spam-protection and queues the messages. The potential impact is that one can block the output. Spamming such messages will delay quassels output and irc interaction. I think the worst case scenario is that quassel core will ping timeout
Upstream believes they have a relatively simple, low impact solution, but are conferring among themselves to make sure. They view this as a vulnerability that needs to be fixed, but not particularly urgent and not critical (the only risk is DoS, not any kind of escalation).
Changed in quassel (Ubuntu): | |
status: | New → Confirmed |
Changed in quassel (Ubuntu Karmic): | |
status: | New → Confirmed |
Changed in quassel (Ubuntu Jaunty): | |
status: | New → Confirmed |
Changed in karmic-backports: | |
status: | New → Confirmed |
Changed in jaunty-backports: | |
status: | New → Confirmed |
Changed in hardy-backports: | |
status: | New → Confirmed |
Changed in jaunty-backports: | |
status: | Confirmed → Won't Fix |
Changed in karmic-backports: | |
status: | Confirmed → Won't Fix |
Changed in hardy-backports: | |
status: | Confirmed → Won't Fix |
FYI, sputnick is one of the upstream developers working on the issue.