Jim Hyslop wrote: > Sequence ID 1 is unused, but 2 is used, so the server can't decrement > the counter. It wouldn't be too difficult to mount a DoS attack on > this scenario. > > I suppose there probably won't be more than a few (dozen? hundred?) > users accessing the repository simultaneously, so it shouldn't be > _too_ difficult to keep track of unused ids.
This is exactly what I had in mind - let the server remember what sequence IDs it has handed out in a DBM or whatever, and only decrement the counter when there are no higher numbers in the DBM. i.e. if the server hands out 1, 2, 3, 4, & 5, and 4 gets used, then when session 5 exits, the server decrements the counter back to 4, but simply ignores sessions 1, 2, & 3 exiting. Should be simple enough. Not sure what would happen with a really heavily loaded system. Sylvain, can you give us any statistics on Savannah? Average number of concurrent users, frequency of commits, frequency all users exit, etc.? > And, of course, this means the numbers won't necessarily be sequential. This is not as important. As long as the server verifies that the session number returned signed by the client is the same as it handed out (or completely ignores any client session numbers, forcing the one it handed out), then a replay attack won't work unless the client happened to get the same session number from the previous commit, which shouldn't be possible with the same CVS server, as currently designed. > Another possibility would be to add a new request/response command to > the protocol, so a client explicitly requests a commit id. OTOH, this > is, if anything, even more vulnerable to a DoS attack. This is a good point, and I hadn't considered it. That's an extra point in favor of the previous idea. > How does CVSNT generate its commit-id? The same way we do, or at least, this was so until Mark committed some code to make ours even more portable and secure. It is a good point that commit IDs could be reused as session IDs, and I had considered it but not made a final decision on it yet. This may be the way to go, as Mark Baushke, Paul Eggert, and I went to some lengths to come up with a method of generation that is unlikely to generate duplicates, but it still falls back on the PID when it can't find the time and can't find a way to generate random numbers quickly. This isn't sure enough to generate unique IDs for portable use as signed session IDs, I think - we just didn't think commit-IDs were worth the trouble yet. Mark, conversely, if a max-session ID does start getting used for the signed-session ID, it could be reused as a commit-id guaranteed to be unique. Derek -- Derek R. Price CVS Solutions Architect Ximbiot <http://ximbiot.com> v: +1 717.579.6168 f: +1 717.234.3125 <mailto:[EMAIL PROTECTED]> _______________________________________________ Bug-cvs mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/bug-cvs
