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?


7 Answers 7


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?

  • 2
    "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, 2012 at 11:35
  • 8
    @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, 2012 at 11:40
  • 1
    @ChrisF: Thanks for putting in words what I wanted to say but didn't know how. Edited answer to clarify.
    – SF.
    Dec 21, 2012 at 11:43
  • It is not always clear that a specific feature written down in a spec is a fault.
    – Doc Brown
    Dec 21, 2012 at 11:47
  • 1
    @DocBrown: Yes - sometimes reduction of security is required as cost-performance tradeoff...
    – SF.
    Dec 21, 2012 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

  • What are the odds for the RAM chip flipping exactly the isAdmin?
    – Random42
    Dec 21, 2012 at 11:57
  • 1
    Very small, obviously, but if it happens, it is a security thread not caused by a software bug.
    – user281377
    Dec 21, 2012 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, 2012 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.
    – Random42
    Dec 21, 2012 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, 2012 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.

  • One man's shortcut is another's back-door exploit. Dec 21, 2012 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.

  • Is it a security risk? It can certainly break your site but can it break the security of your site? Dec 21, 2012 at 21:01
  • 1
    That depends on how wide or narrow your definition of security risk is.
    – Pieter B
    Dec 21, 2012 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.

  • 4
    A probable reason this isn't upvoted more is that the asker explicitly excluded "social hacking". Dec 21, 2012 at 10:31
  • @JoachimSauer Good point. Didn't see that.
    – jgauffin
    Dec 21, 2012 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?

  • 1
    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. Dec 21, 2012 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? Dec 21, 2012 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. Dec 21, 2012 at 10:31
  • @JoachimSauer What if I simply proxy all traffic to the Strict Transport Site, but allow HTTP connections back to the clients? Dec 21, 2012 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". Dec 21, 2012 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.

  • 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". Dec 21, 2012 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, 2012 at 12:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.