pSpaces / goSpace

Programming with Spaces in Go
MIT License
11 stars 5 forks source link

Creating a `go` routine with any operators creates DoS #12

Closed ghost closed 6 years ago

ghost commented 6 years ago

Using go on any of the operators can perform a DoS attack locally or across the network.

There are several ways of fixing this:

  1. Accept that flooding should be a part of goSpace and that the user of the library is responsible for avoiding this situation.
  2. Incorporate barriers that would prevent go by proceeding when many operations are called. This could be an operation queue or counter of how many operations are allowed, throttling the performance of the operations.
  3. Avoiding opening and closing many connections in the tuple space implementations with any protocol.

The following will code will create simple flooding mechanism for a localhost:

package main

import (
        . "github.com/pspaces/gospace"
)

func main() {
        spc := NewSpace("space")

        for {
                go spc.Put("Hello, universe!")
        }
}

Output:

...
ErrSendMessage: write tcp4 127.0.0.1:43914->127.0.0.1:31415: write: connection reset by peer
ErrSendMessage: write tcp4 127.0.0.1:43604->127.0.0.1:31415: write: connection reset by peer
ErrSendMessage: write tcp4 127.0.0.1:44038->127.0.0.1:31415: write: connection reset by peer
ErrSendMessage: write tcp4 127.0.0.1:43824->127.0.0.1:31415: write: connection reset by peer
ErrSendMessage: write tcp4 127.0.0.1:43820->127.0.0.1:31415: write: connection reset by peer
ErrSendMessage: write tcp4 127.0.0.1:44134->127.0.0.1:31415: write: connection reset by peer
ErrSendMessage: write tcp4 127.0.0.1:43980->127.0.0.1:31415: write: connection reset by peer
ErrSendMessage: write tcp4 127.0.0.1:43860->127.0.0.1:31415: write: connection reset by peer
ErrSendMessage: write tcp4 127.0.0.1:44104->127.0.0.1:31415: write: connection reset by peer
ErrSendMessage: write tcp4 127.0.0.1:44094->127.0.0.1:31415: write: connection reset by peer
ErrSendMessage: write tcp4 127.0.0.1:43868->127.0.0.1:31415: write: connection reset by peer
ErrSendMessage: write tcp4 127.0.0.1:43648->127.0.0.1:31415: write: connection reset by peer
ErrSendMessage: write tcp4 127.0.0.1:43776->127.0.0.1:31415: write: connection reset by peer
ErrSendMessage: write tcp4 127.0.0.1:43754->127.0.0.1:31415: write: connection reset by peer
ErrSendMessage: write tcp4 127.0.0.1:43974->127.0.0.1:31415: write: connection reset by peer
ErrSendMessage: write tcp4 127.0.0.1:44028->127.0.0.1:31415: write: connection reset by peer
...

Changing to do it this across network is trivial.

Clearly this depends on protocol and the underlying tuple space implementation, but future tuple space implementations should avoiding opening many connections in order to send of tuples.

albertolluch commented 6 years ago

This is indeed an important issue. It applies to all pSpaces implementations. Together with other security aspects (authentication, access control, secure communications, encryption, ...) it is on my list of future features.

ghost commented 6 years ago

This issue has been temporarily solved in commit 6e4bea2979e88bb19840a6bf365ea4611a497cb1 in the aggregation-policy.

The implementation is slightly throttled, incuring a performance penalty.

Reopen this issue when a proper solution is needed.