[Vortex] hang on quit -- "we still didn't received allreplies"over and over

[Francis Brosnan Blazquez]

> Hi,

Hi Milton,

> this is indeed a weakness in the BEEP protocol, I went through the RFC
> and couldn't find anything regarding this specific issue. It was also
> not evaluated from a security point of view and only regarded as pure
> functionality.

You are right, this could be an exploitable weakness. That's why we
added vortex_connection_shutdown. Having this in mind...

> From a general security point of view, the fact that we always wait
> for a reply when requesting something, means we rely on the "fairness"
> of the opposite peer: its "responsability" to reply :) Well some
> people are not that well educated. I guess every message sent
> (requiring a reply) should require a timeout, ensuring that you ALWAYS
> get a reply, whatever happens at the application layer (protocol
> misuse) or at lower levels (this is pretty much dealt with in the
> current implementation): ensuring correct protocol continuation.
> 
> But I guess having a timeout could be implemented on a per profile
> basis, although it is clearly a BEEP security issue...

..I also think this is a completely profile level problem to be solved
by the application. As everything when you use something you have to
take into consideration what can go wrong and take all required measures
to avoid problems. 

Having security in mind, my view is to always use
vortex_connection_shutdown to close a connection (but I don't have too
much followers for this approach at the office) because your application
could hang for ever (assuming you are using a compliant BEEP RFC
implementation). 

At the core of the issue is found BEEP requirements for closing
sessions. We can provide timeout support vortex_connection_close, but,
at the end, you'll have to call to vortex_connection_shutdown... which
makes me think why wait to finally do the same if all resources are
collected and user application terminates quickly? 

It also makes me think you still have a security problem if the attacker
knows you have some timeout at the closing session. 

Having say that, now think about a remote peer that have replied to all
messages but he denies closing all channels opened. How to solve this
issue? Again, having security in mind and always assuming untrusted
parties, a vortex_connection_shutdown will be required...

Now let's talk about possible solutions:

1) Add vortex_connection_close some support for a timeout causing the
function to fail if something goes wrong. Then application will have to
do a vortex_connection_shutdown if that happens. I don't like too much
this solution as said before.

2) Update vortex_connection_close (or add a new close function) to allow
configuring a handler that receives notification once found events that
would cause the connection to be not closed (i.e channel with pending
transactions or a channel that have denied the close request). I like
this approach a bit more since the attacker won't have any chance if the
application calls to vortex_connection_shutdown in the first erroneous
event received.

3) Or just call to vortex_connection_shutdown when required to close a
connection. This is my preferred approach for untrusted peers. Simple
and goes to the point.

4) Since this is not a new discussion, a long term solution  would be to
propose a new BEEP feature, via RFC 3080, section 5.2, to allow two BEEP
peers to disable the requirement to wait for all pending replies.

However, this don't solve the channel close request denied issue. Then
this quickly moves us to think about proposing a feature that do not
requires a channel to be closed in order to close a session, which is,
at the end, equivalent to call vortex_connection_shutdown.

Comments?

> Milton.
> 
> PS: humm yes I need to update these Gentoo ebuilds ^^

;-) Nice to hear you again Milton!
-- 
Francis Brosnan Blazquez <francis at aspl.es>