I’m not 100% or not whether this falls in like with this particular issue, if it doesn’t, mods, please split to a new topic.
I’m unsure how federation works entirely, but I do know that when I look at my ‘Pod Network’, I have 111 pods that have no version, and 27 pods that return an error. In an effort for optimum security, I’d like to ask if federation actively removes potentially vulnerable pods from the federation network? I’m a Systems Administrator and Engineer and have spent over a decade working in the security field itself (not for an ego boost, but rather to show credibility). Federizing certain vulnerable networks might possibly garner a security vulnerability across the entire federized network.
Again, I don’t know a great deal about how this federization works, so if I’m totally off base, just ignore me
Understandable. Unfortunately, it’s a little difficult to formulate a specific question on such a broad based topic, but I’ll give it a shot?
If one pod has not updated to a newest version which may contain an important security patch, by federation this pod is still connected to your pod and everyone else’s pod. This leads way to several vulnerabilities among the federation network (if my understand is correct, for which it very well may not be). I will list a couple of potential vulnerabilities below, but please note that they may or may not be either valid or alone.
Cross Site Scripting: If one federated pod is on a previous version that somehow allows XSS vulnerabilities, it may be possible to affect the federation drastically by introducing new vulnerabilities, via XSS, which turn into other vulnerabilities that are not XSS based (i.e. database entries which, when federated, could potentially muck up the federation databases)
A database vulnerability could porentially lead to the progression of a rootkit/virus among the federations dissiminated via the browser when utilizing a specific function of the site.
I suppose my point has to be: do we have any methods in which we prevent unauthorized and protentially dangerous actions from being dissemninated to other pods via the federation of those pods due to the connection to potentially vulnerable and/or compromised pods? Is there any future implementation or setup in play to temporarily remove pods from federation until they are in a secure and updated status?
All communication (except fetches) between pod is done using the federation protocol (source code). Messages from other pods are external content, so should fall in the rule “never trust user input”. You don’t need to have an outdated pod for that: someone could very easily set up an evil pod modified to sent evil messages and try to attack other pods. So IMO outdated pods are a problem only for their users, not for the other pods (and if that’s not the case, we are in troubles).
I don’t think it’s the communication itself I’m concerned about. It’s how federated information is stored from one pod’s database to another pod’s database (which is how I’ve seen federation to work…and wonderfully so). Outdated pods have a more likely chance of being affected than updated pods do, for several reasons. If a sys admin cannot keep their server up to date, they run the risk of being vulnerable to a lot more than just their database. You are correct though in that, generally speaking, a pod’s problems should only affect itls normal local users, however, if data is entered into a vulnerable pod’s database, which is then federated, transmitted, and stored on other pod databases, which could then introduce a vulnerability where at one time there wasn’t one?
I understand I’m throwing darts in the dark here and ‘grasping at straws’, I’d just like to understand how this all operates and ensure I’m connected to an enherently safe network (no assumption so far that I’m not, this is all theoretical to me at this point).
That was the point of my previous answer: there is no need for and outdated pod here. Everybody can send federation messages. You can craft a malicious message and send it to my pod from your local computer. So if an attacker wants to use the federation to hack pods, he doesn’t need to find a vulnerability in an outdated pod first, he can do it straight from his computer.
Maybe @denschub or @supertux88 can explain here how diaspora* pod handle malicious federation messages, but I’m sure there is checks there, or we would already be in trouble for years.
Yes, when your pod is vulnerable from messages from others it would be a vulnerability in your pod. It’s always the receiving pod which needs to be able to handle malicious messages.
I’m tagging onto this thread because it might be relevant to something I’ve observed on my pod. I’m currently at 0.7.5 (yes, I know, I will upgrade very soon). A user has reported hacking because a comment has appeared in Russian under her “newhere” post which appears to come from her, but is not from her. (I have seen this behavior on diasporabrazil.org in the past, btw).
Is it possible for a malicious pod to forge a comment by creating the comment locally, changing the author_id, and then pushing the message out via federation?
More generally - has anyone seen the behavior I describe, and if my hypothesis is off the mark, have a better answer?
It shouldn’t be possible, because you need to sign the post with the authors private key, and unless the attacker has that key, the signature would be invalid. If the attacker somehow has the private key (which is only stored on the server or if a users downloads their archive), then there is nothing diaspora can do against it, because that key is everything and with it you can do anything you want with that user.
An attack like this was possible with a very old version of diaspora (I think 0.4.x or 0.5.x?) via the fetch mechanism (because that wasn’t signed), but is fixed since a long time.
What’s more likely to happen is, that the attacker just copies username, avatar and realname from a person and looks like the original, but the domain part is different.
Can you maybe send me more details about that post/comment as private message, so I can have a closer look at it?
