Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I sent a message to my dev manager about a buffer overflow in our (widely distributed) installer, and received a response that it didn't matter as it wasn't server code.

Other than the fact that if it can be fixed, there is no real reason to not, I feel as if I'm forgetting some actual reasons this can be an issue:

  • User experience issues
  • Possible privilege escalation
  • Malformed product key for a reverse connection

I feel as if there are still things I'm not thinking of that I could mention to him as reasons, other than "just because".

share|improve this question
up vote 2 down vote accepted

The only way I can state this with absolute clarity is the following:

A vulnerability is a vulnerability is a vulnerability.

Not patching the problem is an exercise in extreme irresponsibility.

Technical reasons:

  • Possible privilege escalation.
  • Crashes from corrupt input files, leading to bad UX and other nasties.
  • If a user sees an innocuous file (i.e. not an executable), they may assume that it is safe to use, then get pwned when it turns out to be full of shellcode.
  • You could be shipping the installer with security-sensitive software.

Business reasons:

  • Your customers pay you money. Do right by them, because they keep your company afloat.
  • If some blackhat exploits your flaw, it'll be a PR nightmare, and you'll have to fix the bug anyway. It makes financial sense to spend the developer time on this now, rather than later.
  • If the public find out that you knew about this and never fixed it... well, you get the picture.
  • You can and will be sued by companies that lose data due to vulnerabilities in your code, especially if they know you could've prevented it.

Finally, an ethical reason. If your installer is as prevalent as it sounds (e.g. the likes of InstallShield, Nullsoft, etc) you'll most likely have customers whose software is security-sensitive. This could be something as important as TrueCrypt or Tor, where people can literally get hurt or killed over security failures.

Do the right thing. Fix the bug. If he's resistant even after this, you might want to offer to do it on your own time, even if it sucks that you have to work unpaid.

On a slightly less serious note, if I find out I'm running your installer software, and I find out that you have to bitch at management to fix a security bug, I'm probably going to run away from your company like this:


share|improve this answer
That is far more clarity and specification than I have on a Monday morning, thank you. I was slightly unclear on my wording for the installer though, it is for our products (which are still relatively widely distributed) and not a packager like InstallShield etc. – doyler Aug 6 '12 at 15:27
Ah, ok. Still, if you're shipping to customers, 99% of this still stands. – Polynomial Aug 6 '12 at 17:15
Oh I agree, I just wanted to clarify...for the future looks off into the distance – doyler Aug 6 '12 at 18:38

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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