ADC Security Considerations for Hubs

Here is the sub forum used for talking about ideas, implementations and suggestions or typical guidelines.

Further info on extension or the protocol is found at our Wiki
Post Reply
Posts: 53
Joined: 15 Sep 2008, 21:48
Location: adcs://

ADC Security Considerations for Hubs

Post by Dj_Offset » 03 Nov 2008, 22:39

The ADC/1.0 protocol specification gives a few hints about things the hub must take care of in a security related fashion, but not really anything useful.

A fair warning: this post is technical. You need to have at least basic understanding of how the ADC protocol works in order to get anything meaningful out of this post. :!:

Completely basic stuff, not covered elsewhere:

The hub MUST make sure the client sends the correct SID as previously assigned by the hub, for every incoming message to the hub that would contain an originating SID.
Such messages include broadcast messages (Bxxx), direct messages (Dxxx), echo messages (Exxx) and subscriber/feature messages (Fxxx).
Likewise, on NMDC one would have to ensure one used the correct nick name when sending a chat message.
Sending a message that looks like it came from user "good" when it actually comes from user "evil" is just that -- evil, and must not be allowed by any hub.

INF message parsing

Most processing that needs to be performed on the hub is related to the INF-message, so here goes a few of them.
  • The PD-field should always be stripped by the hub, and never relayed to the other users. This is stated explicitly in the ADC spec, although it does not explain why the PD has to be such a "secret" (it has nothing to do with security, that's for sure).
  • The ID-field which contains the CID must not be allowed to be updated after a client has logged in. Updating the ID-field is allowed if it is unachanged, removing it is merely an optimization.
  • The I4/I6 field must match the actual IP address of the user, and that needs to be verifiable, and should not change. Currently the best verification is to check where the user connected from. If a user connected from an IPv4 address one cannot usually determine a valid IPv6 address (unless it's a IPv4 in IPv6 mapping), and if the user's client still reports that it does have an IPv6 address (I6), then the hub must remove that flag as it is unverified.
  • The U4/U6 port numbers should be verified to be within 0 <= port < 65536. Not really security, but let's just call it best practise.
  • There could be multiple flags, such as I4, NI, I6 etc... Make sure only *ONE* of each of these exist (example: BINF (...) NIfoo NIbar --- now, what's the nick, again?)
  • The hub *MAY* support updating or changing the nickname after a user has logged in. Lots of considerations need to be taken here, I will not cover those. It's easier to not allow it if you don't want to do the considerations.
Joining and leaving

Since the hub is required to notify all users about new users joining the hub by sending an INF-message (a 'BINF') message, variants of it must not be allowed.
A client must not be allowed to send a 'DINF', 'EINF' or 'FINF' message, unless the hub can guarantee that it does not change the state for any user who did not receive such a message. The easy solution - drop these messages.
If a client really wants to change information about itself, then all parties would want that information, and as such it should be broadcasted to all as a BINF message, which should be processed and verified by the hub.

A client should not be allowed to 'fake' it's own or some other client's leave message by sending a 'QUI' message.

Chat messages

For messages a client MUST not be allowed to set the PM argument. That is only for the hub to do. Otherwise one can send messages which originate in a particular "window" for the receiving client.

Other things

...are probably forgotten ;)

Post Reply