Mailing List Archive

What is vendor's status regarding this issue?
It is good we found the real cause of DoS effect in Xitami.
Because, the maxedout values seem to work quiet fine, the problem is
Keep-Alive Connection handling.
I don't know how did you actually find out when it has dropped a
particular connection, as in the duration of Keep-Alive affected and
it's connection dropping time and whether it matches the value in configurations? after how long ?
I tried netstat -an frequently by making requests from different hosts on my network, but same results as i told you before.

Regards,
---------
Muhammad Faisal Rauf Danka

Chief Technology Officer
Gem Internet Services (Pvt) Ltd.
web: www.gem.net.pk

_____________________________________________________________
---------------------------
[ATTITUDEX.COM]
http://www.attitudex.com/
---------------------------

_____________________________________________________________
Promote your group and strengthen ties to your members with email@yourgroup.org by Everyone.net http://www.everyone.net/?btn=tag

>What is vendor's status regarding this issue?

I've e-mailed the vendor, but have received no response *at all*.

>It is good we found the real cause of DoS effect in Xitami.
>Because, the maxedout values seem to work quiet fine, the problem is
>Keep-Alive Connection handling.

Yes, I originally thought it was a connection flood because numbers
started jumping and then Xitami crashed almost immediately. However,
I was actually seeing the effects of my flood combined with numerous
other connections that had "hung open".

>I don't know how did you actually find out when it has dropped a
>particular connection

Well, I didn't find out when it was dropping connections, just that
it *wasn't* dropping any. My WinME box btw required an
extremely high number of connections to crash (I believe the number
was over 450), so production machines will require significantly
more connections -- it seems to be a bug-induced resource exhaustion.

>as in the duration of Keep-Alive affected and
>it's connection dropping time and whether it matches the value in
configurations? after how long ?
>I tried netstat -an frequently by making requests from different hosts on
my network, but same results as i told you before.

I'm still a bit hazy on exactly *where* in the keep-alive handling that
Xitami is buggy -- I'm beginning to think that it is not actually related
to an open connection, and instead just a bad resource cleanup on
the server end.

It could be an error in Xitami's dynamic-store allocation logic that causes it to fail to reclaim the discarded memory per connection ?

Call for Memory Leak Detection Tools
http://www.cs.colorado.edu/homes/zorn/public_html/MallocDebug.html



Regards,
---------
Muhammad Faisal Rauf Danka

Chief Technology Officer
Gem Internet Services (Pvt) Ltd.
web: www.gem.net.pk


--- "Matthew Murphy" <mattmurphy@kc.rr.com> wrote:
>>What is vendor's status regarding this issue?
>
>I've e-mailed the vendor, but have received no response *at all*.
>
>>It is good we found the real cause of DoS effect in Xitami.
>>Because, the maxedout values seem to work quiet fine, the problem is
>>Keep-Alive Connection handling.
>
>Yes, I originally thought it was a connection flood because numbers
>started jumping and then Xitami crashed almost immediately. However,
>I was actually seeing the effects of my flood combined with numerous
>other connections that had "hung open".
>
>>I don't know how did you actually find out when it has dropped a
>>particular connection
>
>Well, I didn't find out when it was dropping connections, just that
>it *wasn't* dropping any. My WinME box btw required an
>extremely high number of connections to crash (I believe the number
>was over 450), so production machines will require significantly
>more connections -- it seems to be a bug-induced resource exhaustion.
>
>>as in the duration of Keep-Alive affected and
>>it's connection dropping time and whether it matches the value in
>configurations? after how long ?
>>I tried netstat -an frequently by making requests from different hosts on
>my network, but same results as i told you before.
>
>I'm still a bit hazy on exactly *where* in the keep-alive handling that
>Xitami is buggy -- I'm beginning to think that it is not actually related
>to an open connection, and instead just a bad resource cleanup on
>the server end.

_____________________________________________________________
---------------------------
[ATTITUDEX.COM]
http://www.attitudex.com/
---------------------------

_____________________________________________________________
Promote your group and strengthen ties to your members with email@yourgroup.org by Everyone.net http://www.everyone.net/?btn=tag

Muhammad Faisal Rauf Danka <mfrd@attitudex.com> asked:

>What is vendor's status regarding this issue?

to which "Matthew Murphy" <mattmurphy@kc.rr.com> replied:

>I've e-mailed the vendor, but have received no response *at all*.


This thread is a good demonstration for why vendors need to be
responsive to incoming vulnerability reports. Without a response from
the vendor, we've now got a number of posts in which people have spent
extra time to (a) try to figure out the underlying cause of the issue,
(b) try to duplicate the issue, and (c) try to come up with a
resolution in the absence of vendor guidance and/or a patch. Vendors
often know the answers to these questions.

Greater overall responsiveness by vendors is covered heavily by
section 3 of the Responsible Vulnerability Disclosure Process draft
[1]. Better responsiveness from vendors (and better coordination
overall) can reduce much of this guesswork, so that sysadmins and
security researchers can spend their time on more pressing issues.

- Steve


[1] http://www.ietf.org/internet-drafts/draft-christey-wysopal-vuln-disclosure-00.txt

Steven M. Christey wrote:
> Muhammad Faisal Rauf Danka <mfrd@attitudex.com> asked:
>
> This thread is a good demonstration for why vendors need to be
> responsive to incoming vulnerability reports. Without a response from
> the vendor, we've now got a number of posts in which people have spent
> extra time to (a) try to figure out the underlying cause of the issue,
> (b) try to duplicate the issue, and (c) try to come up with a
> resolution in the absence of vendor guidance and/or a patch. Vendors
> often know the answers to these questions.
>
> Greater overall responsiveness by vendors is covered heavily by
> section 3 of the Responsible Vulnerability Disclosure Process draft
> [1]. Better responsiveness from vendors (and better coordination
> overall) can reduce much of this guesswork, so that sysadmins and
> security researchers can spend their time on more pressing issues.
>

In my opinion bundling bad stuff and good stuff in one document does not make
the whole document good.

When a vendor does not care about security, I simply stop using his product and
don't expect a rfc to protect me and make the vendor a good guy.

Georgi Guninski

>This thread is a good demonstration for why vendors need to be
>responsive to incoming vulnerability reports.

Very true.

It should also be noted that this morning I did receive a response
from iMatix.

>Without a response from
>the vendor, we've now got a number of posts in which people have spent
>extra time to (a) try to figure out the underlying cause of the issue,
>(b) try to duplicate the issue, and (c) try to come up with a
>resolution in the absence of vendor guidance and/or a patch. Vendors
>often know the answers to these questions.

No kidding? Good find. :-)

>Greater overall responsiveness by vendors is covered heavily by
>section 3 of the Responsible Vulnerability Disclosure Process draft
>[1]. Better responsiveness from vendors (and better coordination
>overall) can reduce much of this guesswork, so that sysadmins and
>security researchers can spend their time on more pressing issues.

How convenient. When you are talking about vendors, you harp
on the part that says vendors must be responsible, but you don't
bring up the part that says in order to be ethical I have to leave
people vulnerable for thirty days or more without a peep...

Really, there is no responsible disclosure that can be a one size
fits all policy like an RFC. Experiences even with the same vendor
vary by incident, so you really cannot possibly produce one list
of expectations for so many potentially vulnerable vendors...

I said:

> This thread is a good demonstration for why vendors need to be
> responsive to incoming vulnerability reports... Greater overall
> responsiveness by vendors is covered heavily by section 3 of the
> Responsible Vulnerability Disclosure Process draft

Georgi Guninski said:

>In my opinion bundling bad stuff and good stuff in one document does
>not make the whole document good.

I hope that we can restructure the next version of the document so
that recommendations for vendor responsiveness are somewhat separate
from the proposed disclosure process. That way, vulnerability
researchers/notifiers could point to particular parts of the
disclosure document to give them some "backup," even if they do not
agree with other parts of the document.

- Steve