Michael Poole wrote: >Andrew Miller writes: > > > >>Progs wrote: >> >> >> >>>Hi, >>> >>>If I have two servers, AA and AB, with AAAAA and ABAAA on #foo, a +D channel. >>>AAAAA is delayed on #foo and ABAAA is +d. >>>There are only AAAAA and ABAAA in #foo. >>>When AAAAA speaks on #foo, ABAAA is +d so AB doesn't receive message, so >>>ABAAA doesn't see AAAAA's join. >>> >>>Bug or feature ?:) >>> >>> >>> >>> >>This could be used to build a map of the network and determine where the >>hubs are. Anything which breaks HIS that bad is a bug. >> >> > >Please explain. I don't see any practical way to get useful >information out of this. For leaf servers, having a deaf user in a >channel only tells you whether there are any non-deaf users in the >channel *on the same server*. It does not tell you who they are or >how many there are. You get more information (but not a lot more) if >you allow users on hubs, which does not seem relevant. > > Wouter is correct in his analysis, so see that. I don't think it is a major threat on Undernet, as he is correct that users need to be able to connect to the hubs to perform the attach. However, if they can do that, they can map out how the hubs are connected, and what leaves are connected to them.
>Also, how is the deaf-user case different from the no-user case? > > As Wouter has said, you could perform the attack by simply joining a +D channel after the PRIVMSG has been sent, so +d is not the only issue here. So the true fix would(if it is considered a sufficient security risk) would be to sync the delayed status across the network. This means passing the state at burst time, and flooding the first message that caused a reveal to the entire network. Perhaps we should just drop this, because a network which lets people connect to the hubs probably has bigger problems than whether the networks can be mapped. Best regards, Andrew(A1kmm) _______________________________________________ Coder-com mailing list Coder-com@undernet.org http://undernet.sbg.org/mailman/listinfo/coder-com
