October 19, 2012
by Fredrik Ullner
The community we are part of has had its fair share of security threats. The security threats have originated from software bugs, protocol issues, malicious users and even from the developers of the network.
Security and integrity are very broad terms and my use for them is indeed broad, as I believe they address multiple points and need not necessary simply be about remotely crashing another user. A system’s security and integrity are tightly coupled and may sometimes overlap.
There is a variety in the number of issues we face.
Issue 1: Software issues
Writing software is hard. Really hard. It’s even more difficult when you also include the possibility for others to impact your system (client/hub etc): chat messages, file sharing exchange etc. Direct Connect hinges upon the ability to exchange information with others, so we cannot simply shut down that ability.
A software issue or bug arise differently depending on what type of issue we’re talking about.
The most typical bug is that someone simply miswrote code, “oops, it was supposed to be a 1 instead of a 0 here”.
The more difficult bugs to catch — and consequently fix — are design issues, which can be caused by a fundamental use of a component or the application’s infrastructure, “oops, we were using an algorithm or library that has fundamental issues”.
A security issue may stem from an actual feature — for instance the ability to double click magnet links. That is, the bug itself is that the software is not resilient enough for a potential attack. That is, there’s nothing wrong with the code itself, it simply isn’t built to withstand a malicious user. (Note: This is not a reference to the magnet links, they were simply an example.)
A software bug may not only cause malicious users or (other) software to exploit the system, they may also cause the integrity of content the crumble. For instance, pre-hashing, the ability to match different files to each other were done via reported name and file size. This was ultimately flawed as there was no way of identifying that the two files were identical, beyond the name and size, both of which can be easily faked.
A software issue may be addressed by simply blocking functionality (e.g., redirects to certain addresses, stopping parsing after X character etc). While this is the simplest course of action, removing functionality is often not what users want.
Issue 2: Protocol issue or deficiencies
Systems and protocols that allow users to perform certain actions carry with them a set of potential security issues. The problem with writing a protocol is that other people need to follow it: the developers of a piece of software may not be the same as the developers for the protocols. For Direct Connect, there’s a very close relationship between the two groups (it’s actually closer to one group at the time of writing), so this issue may not be that severe. However, there will always be a discrepancy between the maintainers of the protocol and software. Imagine the scenario where the developers for a software suddenly disappear (or are otherwise not continuing updates). The developers for the protocol cannot do anything to actually address issues. In the reverse situation, the software developers can simply decide for themselves (effectively creating their own ‘protocol group’) that things need to be updated and do so.
Any protocol issue is hard to fix, as you must depend on multiple implementations to manage the issue correctly. The protocol should also, as best as it can, provide backwards compatibility between its various versions and extensions. Any security issue that comes in between can greatly affect the situation.
A protocol issue may also simply be that there’s not enough information as to what has happened. For example, the previous DDoS attacks were possible to (continue to) do as there weren’t an ability for the protocol to inform other clients and hubs (and web servers etc) what was happening.
The original NMDC had no hashes and as such no integrity verification for files. This was a fundamental issue with the protocol and extensions were provided later on to manage the (then) new file hashing. This wasn’t so much a bug in the protocol, it was simply that it was a feature NMDC’s founder hadn’t thought of.
When software is told to interact in a certain way according to the protocol, then those actions are by effect the protocol’s doing. For example, the (potential) use of regular expressions for searches are not a problem for the protocol itself: the specification for regular expressions in ADC is quite sparse and very simple. However, the problem with regular expressions is that they’re expensive to do and any client that will implement that functionality effectively will open themselves up to a world of hurt if people are malicious enough. While the functionality lies in the software’s management of the feature, it is the protocol that mandates the use of it. (Note: In ADC, regular expressions are considered an extension. Any extension is up to the developers to implement if they so choose. That is, there is no requirement that clients implement regular expressions. However, those that do implement the functionality of the regular expressions, are bound by the protocol when they announce so.)
Issue 3: Infrastructure
The infrastructure of the system must withstand security threats and issues.
If a hosting service would go down for a particular software, then that software cannot make updates responding to upcoming issue. Official development simply stops at that point on that service (and the developers need to find another route).
If a hosting service decide to remove old versions (say, because it had a 2 year pruning of software or for legal matters) then someone need to keep backups of the information.
A large part in the DC infrastructure is the ability to connect to the available hublists. This issue was apparent a few years ago when the major hublists were offline while various software didn’t update. People simply couldn’t connect to hubs, and for beginners this is even more annoying. There are now various mitigation approaches to handle these scenarios, such as local caching, proxy/cloud caching and even protocol suggestions to handle these scenarios and distribution avenues.
Infrastructure isn’t simply being able to download software and connect to a hublist, it is also the ability to report bugs, request features and get support for your existing software and resources.
A very difficult problem with infrastructure is that it is often very costly (money) (for the developers) to set up. Not only that, it must be properly done, which is also costly (time) and hard. Moreover, most people aren’t experts at setting up resources of this kind, and there is lots of information available online for avenues of attacks against forums and websites.
Infrastructure issues can be aided by moving some services out in a distributed manner (whilst a set of people maintain the resources) and moving some services out to the users in a distributed manner (for example, allowing clients to automatically exchange hub lists). Obviously, the services must be there from the start, otherwise there’s little one can do.
Issue 4: People
Software, infrastructure and our ideas only last so far. If a person has the means and intent, they can cause various problems for the rest of the community. Most of the time, we envision a person trying to cause havoc using a bug in the system (or equivalent) but that is not the only concern we have when it comes to people and their interactions.
While a person with the know-how and the tools can cause a tremendous problem, the people that can cause the most problem are those who control key resources within the system. For example, a hub operator may cause problems in a hub by kicking and banning people. But the hub owner can do much more than that, since they control the very resource that people are using.
That means the developers and owners of each resource must guard themselves against others who they share that control with. This is primarily a problem when the two (or more) people who share a resource disagree with an issue, and one party decide that they want to shut down that resource. The last instance of this was last year and was with ADCPortal and other similar problems have occurred in the past.
The problem with this is that we all need to put trust in others. If we don’t, we can’t share anything and the community crumbles. A problem with resource ownership and control is a general problem of responsibility: if I own a resource (or have enough control over it), I am expected to continue developing it and nurturing that resource. If I do nothing as a response to security issues (and any other issue) then that resource eventually needs to be switched out.
The solution is to share resources in such a way that allow people to contribute as much as possible. The community should encourage those who are open about content, and try and move away from a “one person control everything” system. This is extra difficult and puts the pressure on all of us.
The road ahead
Security cannot be obtained by not addressing the problems we face. The community gain very little by obfuscating the ‘when’ and ‘how’ when it comes to security: it only slows down any malicious party so much by not being open about the security issues we face.
Disclosure of security issues is an interesting aspect and the developers owe it to the community to be as direct as possible. It does not help if we wait one day, one week or one year to inform people, anyone vigilant enough will discover problems regardless when and how we announce them. Any announcement (or note in a changelog or other way of information) shouldn’t cause people to treat the messenger badly. Instead, the key is to have an open dialog between developers, hub owners, users and anyone else involved in the community. The higher the severity of the security issue, the more reason to treat any potential forthcoming issue directly and swiftly. I believe it would also be good if someone reviewed past security issues and put them together in a similar article or document, essentially allowing current and future developers to see problems that have been encountered and hopefully how they were solved (this has been done to a certain extent). Discussing security issues with security experts from various companies may also be a way forward.
The community must be active in security and integrity issues. A common phrase for development is to be “liberal what you accept and conservative what you send out”. This applies to both software and protocol development.
Software should have clear boundaries where input from another user or client can cause an impact.
Protocols should be reactive in what hashing methods, algorithms and general security it uses. The new SHA-3 standard is interesting in this aspect, and it would be good if we would switch to something that provide a higher security or integrity for us. Direct Connect has gone from a clear-text system to a secure-connection system (via TLS and keyprints). The system could further be extended with the use of Tor or other anonymous services, to provide that anonymity that other systems have.
The security of our system shouldn’t depend on “security by obscurity”; before DC++ added an IP column to its user list, people (incorrectly) believed that their IP was “secret”. The security of our system shouldn’t depend on obfuscating security issues, since they’ll only hit us even harder in the future. There are other cases where the normal user doesn’t know enough security aspects. For example when people disclosed how you could as a hub owner sniff out all data from their hub and their users’ interactions. While I strongly believe it’s difficult to educate your users (on any topic, really), you shouldn’t lie to them. Provide instead ample evidence and reassurance that the information is treated with care and that you as developers and fellow user consider security an important point.
Security is tricky because it may sometimes seem like there’s a security issue when there’s in fact not. This makes it important for us to investigate issues and not rush for a solution. It is also important that people don’t panic and go around yelling “security problem!”, as if there’s no tomorrow (I’ve been the source of such a scare, I’ll admit). Equally important is that those who knows more about security should be the decider of protocol and software aspects, as the topic shouldn’t be subject to whimsical changes “because it makes no sense, right?” (I’ll once again, unfortunately, admit of being the cause of such an issue, regarding ADC — but hopefully will be rectified soon-ish).
The road ahead is to investigate security issues in a timely but proper manner, be pro-active and be up front with problems. Time should be spent to investigate a component’s weaknesses and that component should then be discarded if the hurdles are too difficult to overcome.
Direct Connect: Just These Guys, Ya Know? 
You must be logged in to post a comment.