Should security-critical code be reused or rewritten?

Question

Usually, in programming, reusing code is always a better idea than writing your own implementation of an algorithm. If an implementation has been around for a long time and is still used by lots of projects, it is likely to be pretty well designed to begin with, have received plenty of testing and debugging, and perhaps most important someone else is in charge of maintaining it which means more time to focus on the specific software product that you are building.

However, I was wondering if this principle still holds true for security-critical code, which performs tasks such as encryption and authentification, or which runs with high privilege for any reason. If one implementation of an algorithm is shared by lots of software systems, then there is a strong incentive for people to crack it, and when a flaw is found in it, it is likely to be a massive security disaster. Heartbleed and Shellshock are two recent examples that come to mind. And for closed-source examples, pick anything from Adobe :)

Many different pieces of software sharing a single security-critical library also makes this library a target of choice for attackers wanting to insert a backdoor in it. In a large open-source project with lots of activity, a backdoor commit which also features plenty of other corrections (such as a code style cleanup) as a decoy is unlikely to be noticed.

With all this in mind, is code reuse still considered a good practice for code doing security-critical tasks? And if so, which precautions should be taken to mitigate the aforementioned weaknesses of that approach ?

Answer 1

The important thing is maintenance. Regardless of whether you reused existing code or wrote your own, you will achieve decent security only if there is someone, somewhere, who understands the code and is able to keep it afloat with regards to, say, evolution of compilers and platforms. Having code without bugs is best, but in practice you must rely on the next best thing, i.e. prompt fixing of bugs (especially the bugs that can be leveraged for malicious usage, also known as vulnerabilities), within a short time frame.

If you write your own code, then the maintenance job relies squarely on your own shoulders. And that job can be very time-consuming. For instance, if you decide to write and maintain your own SSL/TLS library, and use it in production, then you must understand all the peculiarities of cryptographic implementation, in particular resistance to side channel attacks, and you must keep an eye on published attacks and countermeasures. If you have the resources for that, both in time and competence, then fine ! But the cost of maintenance must not be underestimated. Reusing an existing library, especially an opensource one that is widely used, can be quite cheaper in the long term, since maintenance is done by other people, and widespread usage ensures external scrutiny. As a bonus, you cannot be blamed for the security holes in an external library if half the World shares them.

To sum up, the question is not really about code reuse, but about maintenance effort reuse.

(I write all this independently of the great pedagogical qualities of writing your own code. I encourage you to do your own implementations -- but certainly not for actually using them in production. This is for learning.)

Answer 2

Even more so.

Security code is tricky. Cryptography code is downright hard, even if you are a trained cryptographer - and impossible to get right, if you are not.

If there are so many critical bugs in so many big important software packages and companies - what makes you think* you would be able to do a better job?

_{* Unless of course this is your specific realm of expertise, and the security functionality is core to your product...}

Answer 3

Interesting question! I'd like to answer it more from probability standpoint, than from Best Current Practices standpoint.

While Thomas and others provide great answers, I do not think they touch on the core question - which is "is unique (or less used) code more resilient in practice than popular code". Note that I've deliberately not used "more secure than popular code". And what that boils down to is special case of "does security through obscurity work"?

And (and I know this is not going to be popular answer) I think when we replace "secure" with "resilient" the answer might not actually always be commonly accepted "never!"

It stands that it is probably less secure (meaning: it is very likely that your own security code is easier/faster to crack than popular one which was being through many attacks before, and fixed by smarter persons than you).

However, unless you are big/popular site, it also stands that you are much less interesting to potential crackers if they cannot reuse the code/effort spent in cracking you, and that effort is non-trivial (meaning, your site will not break down at automated parameter non-validation / SQL injection probes). This obviously doesn't work if you're targeted specifically (industrial espionage etc.), but vast majority of attacks those days actually seem to be automated probes for popular software.

So, if the question is not "which is more secure", but "which is less likely to be cracked", answer might actually be "it depends". Here are few examples:

Example 1: Imagine Microsoft windows 8.1 (or whatever is popular these days) computer, with currently no known security holes, bought but never updated, connected to the Internet. Also imagine decades old Windows 3.11 with winsock, never patched, with known hundreds of security holes, connected to Internet. Both are used in same manner. Ignore for the purpose of discussion quality of access... Question is, which will be broken into sooner?

While it is obvious that 3.11 is much less secure, there are hardly any exploits in the wild targeting it. So it might well be that there would be massively popular 0-day exploit for 8.1 hitting it, before 3.11 hits some archaic exploit that manages to run on it.

Example 2: Imagine you have latest Joomla CMS on one web server with no known current exploits, and hand-made perl script doing CMS-ish things, with known exploitable bugs (but none of them suspicious to currently available automated tests). After one year, which has greater chances that it will be exploited?

While anecdotal evidence, in few dozens (to hundreds) cases I've had in past decades, it was in great majority of cases that popular software was exploited, while the obsolete ones continue to run to this day undisturbed.

Another things worth considering:

• if popular software does autoupdate (or has admins ALWAYS updating it promptly), then the weaknesses of such popular code is much reduced (but not eliminated, due to 0-day and unpublished exploits) and thus has great advantage
• conversely, if software is going to receive no maintenance, non-popular (like self-written) one might actually be less suspect to problems
• blame - it might often be advantageous to use popular software. If half the world is affected, you won't get nearly as much blame as if you were single programmer on it. This is especially important if working with money. It's often "better" there to be less secure but being able to shift the blame, than to be more secure but having to carry the cost yourself when exploit does hit.
• work - already mentioned by others, popular software will in vast majority of cases fix itself, you just need to update - which is much less work than actually finding and fixing bugs yourself (but still requires some maintenance)
• another advantage for self-written software is often mass code reduction (leading to less bugs), as you usually don't need most of the features or customizability. For example, people will use Joomla even if all they need is simple "template news site" which could in practice be accomplished with few dozen lines of code. Even if you as programmer are not half as good as the accomplished ones working on popular piece of software (so you have noticeably higher number of bugs per line of code), you can often still win by large margin due to having order of magnitude (or few!) less code to write/maintain

Answer 4

The simple answer is: don't roll your own security.

There are two parts to this. Algorithm and implementation.

As for the algorithm, creating your own encryption algorithm is horrendous. Even if you are versed in the field of cryptography, you still aren't in a position to create a new algorithm. Unless you have a team of experts in the field working on it, you do not roll your own algorithm. To drive home this point, look at some of the recent algorithms that have been cracked and how they were cracked. What looks great at face value has weaknesses that I would've never conceived.

As for implementation, creating your own implementation of a good algorithm is not as horrible as creating your own algorithm, but unless you are a professional at it, don't do it. One mistake in implementation and it won't matter how good the core algorithm was. In this case, the question you have to ask is if you are better than the many experts who worked to put together a top of the line security library.

What is more likely. That you can roll your own algorithm and implementation without any errors or weaknesses or that the algorithm and implementation you use is going to have a backdoor put in?

If you could create a perfect algorithm with implementation, the risk of the backdoor would not be an issue. But that isn't realistic.

There is also the question of which you want to be explaining to your manager/shareholders/ect.? That there was a backdoor put into some top of the line trusted software package that has the entire industry running around or that your personal attempt at better security failed horribly. I personally would much rather explain that I made the choice that professionals all over the industry made and the only reason it failed was some massive level issue that is impacting even multinational corporations.

That said, I agree with Thomas that trying to do it yourself is a good learning experience as long as it never sees the light of production.

Answer 5

Security is not necessarily improved simply if the code compiles to slightly different instructions. Security is:

1. Algorithm
2. Implementation
3. Auditing
4. Maintenance

If you are not writing better, more secure algorithms -- which may take years of research -- and are not having your code audited, and patching accordingly, then simply a slightly different implementation is very unlikely to make you secure.

Heartbleed, Shellshock, BEAST, POODLE, and other last several major SSL/TLS issues have occurred due to problems inherent in CRC and self-referential algorithms themselves, and lack of experienced code audits, not due to implementation.

If you don't really understand how they failed, you definitely should not be writing your own security code. You'll add more problems than you'll solve.