

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer

Most security threats that I've heard of have arisen due to a bug in the software (e.g. all input is not properly sanity checked, stack overflows, etc.). So if we exclude all social hacking, are all security threats due to bugs? In other words, if there were no bugs, would there be no security threats (again, excluding the faults of humans such as disclosing passwords and such)? Or can systems be exploited in ways not caused by bugs?

share|improve this question
Do you call the possibility that I could guess a weak password a software bug? If anything, it's a design problem, but it's probably even more fundamental than this. – Joachim Sauer Dec 21 '12 at 9:26
Would you define poor design as a bug? – StuperUser Dec 21 '12 at 9:37
To support @StuperUser, in the link "…; there is no bug in Dave's script. But it is stupid design. – Manoj R Dec 21 '12 at 9:39
If we exclude all reasons for security issues, except bugs, then yes. – andho Dec 21 '12 at 12:03

A bug is defined as software not operating up to specs. Now if specs are faulty, it's not a software bug. If a dumb customer demands all passwords must be three-digit codes with no grace period between faulty entries, it's not the software that is to be blamed.

Many systems have "service mode" that can override the security, and while access to it should be secure, the codes often leak to the public.

Advances in mathematics compromise old cryptography methods. Something that was viable security 30 years ago becomes weak nowadays.

There are various methods of data theft that are often overlooked. A wireless keyboard has about 2m range, due to tiny antennas, and the code sent is unencrypted. Reading it out from across the street with a good antenna is a well-known method.

Sometimes security trade-offs are made with full awareness of consequences - crypto systems take power and CPU time. Embedded monitoring applications often send their data in a way clearly readable to the public because first, the value of compromising the data is negligible, and then the extra cost of implementing the security is unnecessary.

All security is based on trust. It takes no social engineering for the appointed admin to go rogue and read your mail.

And in the end, can one consider applying baseball bat to a knee a social technique?

share|improve this answer
"if specs are faulty, it's not the bug" hm this wording sounds slippery. I'd say "it's bug in spec" instead. When I've been a tester I successfully submitted and verified fixes for few dozens of such bugs. And as a developer I had a chance to fix some of such "spec bugs" reported by testers against API docs I was assigned to maintain... – gnat Dec 21 '12 at 11:35
@gnat - However, a "bug in the spec" is not a software bug, it's a design bug. Unless you could the design as part of the software of course. It all depends on where you draw the line. – ChrisF Dec 21 '12 at 11:40
@ChrisF: Thanks for putting in words what I wanted to say but didn't know how. Edited answer to clarify. – SF. Dec 21 '12 at 11:43
It is not always clear that a specific feature written down in a spec is a fault. – Doc Brown Dec 21 '12 at 11:47
@DocBrown: Yes - sometimes reduction of security is required as cost-performance tradeoff... – SF. Dec 21 '12 at 11:50

There can be situations where hardware bugs cause security issues, too. Just consider a faulty RAM chip that spontanously flips the "isAdmin" bit.

Or consider a hypothetical hardware bug where the memory protection doesn't work as expected and one process can overwrite another process' memory without triggering an interrupt.

For your reading pleasure: Computer security compromised by hardware failure

share|improve this answer
What are the odds for the RAM chip flipping exactly the isAdmin? – m3th0dman Dec 21 '12 at 11:57
Very small, obviously, but if it happens, it is a security thread not caused by a software bug. – user281377 Dec 21 '12 at 13:01
A chance of a computer system corrupting the permission bits on random files is entirely possible. A file that is globally writable and SUID root can be trivially edited to elevate user permissions. – SF. Dec 21 '12 at 13:38
@user281377 You do realize the probability only for selecting exactly the isAdmin bit from all the bits is 1/34359738368 for a machine with 4 GB of RAM; this, ignoring the probability for a wrong chip flipping. – m3th0dman Dec 21 '12 at 14:01
@m3th0dman You probably misunderstand me. I'm not saying that this is a major problem everybody must care about. It's more like a theoretical proof that a hardware problem can create a security thread. That said, it's imaginable that an attacker who discovers the faulty bit(s) on a server might find ways to pad his input until something critical is put on those memory locations. – user281377 Dec 21 '12 at 21:15

Lots of security threats arise from software features, not bugs. Lots of very useful software features turn out to have uses for good or evil, depending only on the user's intent.

share|improve this answer
One man's shortcut is another's back-door exploit. – Daniel Hollinrake Dec 21 '12 at 9:48

Consider a distributed denial of service attack (DDOS). That can be a security risk, but it's not caused by a software bug but rather by an attacker going over the limits of what the system was designed for. And every system has a limit.

So the answer to your question is: no, not all security threats are triggered by software bugs.

share|improve this answer
Is it a security risk? It can certainly break your site but can it break the security of your site? – Carson63000 Dec 21 '12 at 21:01
That depends on how wide or narrow your definition of security risk is. – Pieter B Dec 21 '12 at 21:26

Social engineering.

Hello, I'm XX from the IT department. Your computer is currently spreading viruses to other office computers. I need your username and password to be able to remove it.

When the hacker have got the username/password he can safely install trojans etc.

Social engineering can be applied in several ways and using it to circumvent security is one.

share|improve this answer
A probable reason this isn't upvoted more is that the asker explicitly excluded "social hacking". – Joachim Sauer Dec 21 '12 at 10:31
@JoachimSauer Good point. Didn't see that. – jgauffin Dec 21 '12 at 10:56

How about something like Firesheep, the Firefox addon that steals cookies being transmitted on a shared wireless network?

You could argue that vulnerability to such attacks is a bug, but you could also argue against it as well. There's not much a website can do to avoid users being compromised other than just running all communications over HTTPS - can you say that it's a bug to accept HTTP communications on your website?

share|improve this answer
I'd categorize the decision to transfer important, private information over an un-encrypted medium a design error. If this should be considered a "software bug" is a separate discussion, in my opinion. – Joachim Sauer Dec 21 '12 at 9:37
@JoachimSauer, what if your website refuses to transfer any information over HTTP and it's actually a MITM who's mapping HTTP to HTTPS? While browsers support HTTP and routers permit it to pass there's a vulnerability to sniffing which can only be avoided by extremely security-conscious clients. So really the question becomes: is it a bug for web browsers to support HTTP? – Peter Taylor Dec 21 '12 at 9:59
@PeterTaylor: for this problem there's HTTP Strict Transport Security, which basically ensures that the browser knows that your site should only be visited via a secure connection. Also: the asker explicitly excluded "social hacking" and depending on the user to ignore an unsecured line could be considered to be contained in that aspect. – Joachim Sauer Dec 21 '12 at 10:31
@JoachimSauer What if I simply proxy all traffic to the Strict Transport Site, but allow HTTP connections back to the clients? – Joshua Drake Dec 21 '12 at 19:20
@JoachimSauer: Indeed, I agree with you. It is unwise architectural design decisions that cause this vulnerability. Not anything incorrectly implemented in code, which is what I'd term a "bug". – Carson63000 Dec 21 '12 at 21:00

Yes, insofar as a failure in the software's security is—whatever the proximate cause—a failure by the software to fulfil its requirements.

I accept that this is just a tautology, but that's the measure of it.

share|improve this answer
Sometimes security is simply not a (defined) requirements. And if it's added to the list of requirements after the security breach, I wouldn't call it a "bug". – Joachim Sauer Dec 21 '12 at 11:30
Just because a requirement wasn't elicited at the start of a project, @JoachimSauer, doesn't mean it wasn't required. The software industry has spent longer than my lifetime on dealing with that fact. – user4051 Dec 21 '12 at 12:09

Your Answer


