[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: omorrow's 0.37

From: Ben Reser <ben_at_reser.org>
Date: 2004-01-24 09:38:50 CET

On Sat, Jan 24, 2004 at 12:20:20AM -0600, kfogel@collab.net wrote:
> kfogel@collab.net writes:
> > to Do The Right Thing. So I think this is worth having. (I'm not
> > sure I agree with the DoS claim in STATUS, because the DoS attack is
> > still there -- all the attacker has to do is not shut down the socket.
> > But it's still a stupid bug with ugly server-side consequences.)
>
> Looking at issue #1709, it seems that in some environments, there
> really is a DoS attack unique to r8463. In Greg Stein's words from
> the issue: "Without the network I/O present to throttle the CPU, it
> takes all it can."

I hope this IRC transcript helps people in understanding the issue from
a security standpoint.

11:17 < ghudson> sussman: Did you read jackr's last comment in issue
                 #1709?
11:18 < ghudson> dionisos: The definition varies. But I don't think
                 fixing #1709 makes it particularly harder to DOS an
                 svn server.
11:18 < dionisos> hmm. ok. I have to think about that one...
11:19 <@sussman> hm
11:19 < ghudson> Hm, I suppose the network does act as a throttle on
                 httpd's CPU usage when the checkout is progressing
                 normally.
11:19 <@sussman> yah
11:19 < jackr> ghudson: my last comment was "my case ain't like the
               others," but then everybody else says "me, too," so I
               think my last is essentially void....
11:19 <@sussman> people were complaining that their httpd jumped to
                 100% cpu
11:20 < ghudson> jackr: No, your last comment isn't void. The point
                 is, httpd will eventually finish the checkout and
                 return to normal. It's doing more work than it has
                 to, but no more work (in total) than it would be doing
                 if the checkout had proceeded.
11:20 <@sussman> so it's not a DoS in the sense of "bringing down a
                 server"
11:21 <@sussman> it's just an easy way to make a server's cpu load spike
11:21 <@sussman> for a few minutes.
11:21 < ghudson> I guess it's sort of a DOS situation if the unthrottled
                 httpd is competing too hard against the other work the
                 server is doing. Later comments in the thread seem to
                 indicate that the server isn't hurt all that badly.
11:21 < ghudson> My point is, if I want to make the server do that much
                 work, I can just do a checkout.
11:22 < jackr> It could be used to reduce the "D" needed for a "D"DOS
11:22 < holsta> DDoS != DoS
11:23 * sussman files an issue: 'svn checkout' == potential DoS!
11:25 < jackr> the server doing this dance is using more CPU (but less
               of other resources) than the one doing a healthy checkout
11:25 < ghudson> Let's say I want to DOS svn.collab.net. With the
                 current bug, I can start ten checkouts and close the
                 sockets, and that will cause a high load on the CPU.
                 Without the bug, I can start ten checkouts and throw
                 the resulting data away, which will cause a lower load
                 on the CPU but also a big load on the network. I
                 suppose if I don't have a big pipe, my ability to
                 figure out which ACKs I need to send to keep the data
                 flowing is limited.
11:26 < jackr> But still, the order of the problem to DoS with or
               without this defect is pretty much the same.
11:27 < holsta> Even from a 'application responsiveness' this should be
                fixed; never mind the CPU usage.
11:28 < holsta> People are going to be pretty annoyed if they have to
                wait for minutes simply because they abort a checkout.
11:28 < jackr> holsta: +1. Just meant "it's not really a security
               thang."
11:29 < holsta> security thong. Now there's a thought.
11:29 < jackr> Ouch!
11:30 <@sussman> wait for minutes?
11:30 <@sussman> there's no waiting.
11:30 <@sussman> the client disconnects and quits.
11:30 <@sussman> then httpd keeps spewing data at the dead socket,
                 spiking up the cpu load.
11:31 < holsta> Hm, I got that impression from Heap's session transcript
                in the bug.
11:31 < jackr> yeah, we shouldn't muddle this with that other problem:
               ^C doesn't work.
11:32 < jackr> Still, if I so something like "svn co -m'bogus comment'
               http://repo/with/lots/of/stuff", then kill it, fix the
               comment, kill it, fix the comment again, kill it, ...
               Pretty soon, I'm turkey-DoSsing the site.....
11:32 * jackr has been there
11:32 < jackr> s/so something/do something/
11:32 <@sussman> I just wanna know if anyone is going to veto the
                 change, before I bother to review it.
11:34 < dsp> VETO
11:34 < dionisos> no veto; I think it's a good thing. (no +1 either; I'm
                  too bus y with other stuff atm)
11:36 < ghudson> I'm not going to veto it.
11:38 * sussman reviews
11:42 * dionisos wonders if sussman reads philips mail while reviewing...
11:43 < breser> The issue with this as DoS issue is not that it's unique
                in the amount of work it creates for the server, but that
                it allows a client to request the server to do work
                without the overhead of receiving it.
11:43 < breser> It creates a situation where with very little resources
                you can hurt the server.
11:43 < breser> Whereas a large checkout while actually listening would
                requiring receiving a large amount of data.
11:44 < breser> This makes an attackers potential effect greater than he
                would ordinarily be able to have.
11:44 < djh> sussman: The client does wait for a long time after Ctrl-C
             a checkout
11:44 < breser> Now granted a DDoS attack negates the value in that.
11:45 < breser> The DDoS attacker doesn't care about the resources he is
                using generally and has a lot more resources in
                aggregate than the server is likely to have.
11:46 < breser> So it's not a DoS issue in and of itself. It just makes
                it easier to carry out a DoS attack.

-- 
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jan 24 09:39:29 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.