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