search

solana-labs / solana

Web-Scale Blockchain for fast, secure, scalable, decentralized apps and marketplaces.
https://solanalabs.com
Apache License 2.0
13.22k stars 4.31k forks source link

Gossip pull requests and repair requests do not sign the destination pubkey #9542

Open aeyakovenko opened 4 years ago

aeyakovenko commented 4 years ago

Problem

Nodes can maliciously replay messages and spam the network

Proposed Solution

  1. sign the destination pubkey

it doesn't need to be sent with the message, the receiver and sender can just assume the message ends or starts (whatever is simpler) with the receiver pubkey.

tag: @sakridge @carllin

aeyakovenko commented 3 years ago

@behzadnouri are we still vulnerable to this after the ping pong protocols?

behzadnouri commented 3 years ago

@behzadnouri are we still vulnerable to this after the ping pong protocols?

I think there are different attack scenarios:

  1. Message from a to b is replayed on a different node c: Then including destination pubkey in the payload and including that in the signature would prevent this. For example prune has to do so (otherwise an attacker can completely exclude a node from push messages): https://github.com/solana-labs/solana/blob/d4ffd909a/core/src/cluster_info.rs#L233-L245

  2. Message from a to b is replayed on the same node b: Then including a nonce in the requests and returning that nonce in the response can help. So that b can verify if it was still expecting a response from a for that nonce token, and otherwise discard the message. https://github.com/solana-labs/solana/pull/16512 verifies nonce in repair. cc @sakridge to confirm if that is all done for repair. https://github.com/solana-labs/solana/blob/d4ffd909a/core/src/serve_repair.rs#L95-L97

    • Additionally, node a can keep track of recent (nonce, wallclock) of requests it has received from b and discard requests with duplicate nonce token as replayed, and not respond to them.
    • Gossip is not using any nonce, but I can add that.

  3. The network receives pull-requests from a spoofed ip address a.b.c.d. Then the cluster can be hijacked to run a ddos against an ip address outside of the solana cluster. Neither of (1) signing destination pubkey nor (2) including nonce token can help here, as the attacker can include them as well. But ping/pong would prevent this by sending (rate limited) ping packets first to that ip address and only responding to ip addresses which have responded to pings.

    • Also for outgoing pull-requests we need to verify the IP address is indeed part of the network and someone is not pushing phony contact-infos into gossip: https://github.com/solana-labs/solana/pull/16748
    • In some way ping/pong is in the opposite direction of nonce. The receiver pings the sender to verify its ip address, whereas the sender generates and includes nonce in its requests, so that the receiver will include that nonce in its responses.

So ping/pong wouldn't really do anything for replay attacks. Instead we need both (1) and (2). I will work on adding those to gossip messages. Repair might also need to include and sign the destination pubkey in the message.

cc @sakridge @carllin

mvines commented 3 years ago

AFAICT, repair responses are also not signed. This could be an another spam vector