Possible severe security vulnerabilities that could go unnoticed for a long time

Question

I've been wondering about this for a while after reading through an interesting article a while ago (probably old news for some of you here) about a technique which one could use to introduce intrinsically hidden backdoors in compilers (article here). Another interesting article: (Did NSA Put a Secret Backdoor in New Encryption Standard?).

Which other methods can you think of that could threaten data security (in the broad sense) and could go unnoticed for a (very) long time?

I'm making this community wiki. Let the paranoia go!

Answer 1

This may not be a complicated one, but doing an assign operation instead of a comparison could be a big hole that's easily overlooked:

if (userRole = "admin") { ... }

instead of:

if (userRole == "admin") { ... }

Lately, I've taken to putting my constant or literal as the first part of the conditional, like so:

if ("admin" == userRole) { ... }

So that if I ever mess up the comparison operator, the code will bomb right then and there during testing, instead of silently giving the user "admin" privileges.

Answer 2

Having just seen a round of code fixing things like this, using an insufficiently secure random number generator is a great way to open yourself up to security vulnerabilities, and do so in a way that won't be detected until you're subject to a deliberate attack.

As an extreme example of this, consider the Debian openssl/ssh/etc vulnerability. That that went undetected for only just under two years is amazing - in something less wide-spread than Debian, I imagine it would lie buried for at least twice as long.

As a simpler example of something that's insecure, consider java.util.Random. This uses a very simple and very fast algorithm to go from one random number to the next, has only 48 bits of internal state, and if you ever generate a 64-bit number from it that you expose to the user, you've then exposed to the user all of your RNG's internal state. (A replacement for java programmers is the aptly named java.security.SecureRandom class)

Yes, in some sense it's "just" a matter of educating programmers to pay attention to when they're generating a security-sensitive random number and when they aren't, but you only need to miss one spot in your authentication-token code to really screw you.