4 ms·

That is entirely fallacious reasoning. Your programs could be full of exploitable bugs (and they probably are) yet nobody knows or cares enough to exploit them.

That is entirely fallacious reasoning. Your programs could be full of exploitable bugs (and they probably are) yet nobody knows or cares enough to exploit them. OpenSSL had trivial errors unchecked and presumably unexploited for years.

nineteen999 8y ago
Or maybe we know the program we inherited has flaws, and we don't connect it/publish its source code to the internet claiming it's fit for general purpose use, and we strive everyday to provide new mitigations and defense in depth to prevent its exploitation. But you go ahead and believe it's because of dumb luck if you like.
- zeroname 8y ago
  You made a simple If-this-then-that claim that was a non-sequitur, that's my only point. > we strive everyday to provide new mitigations and defense in depth to prevent its exploitation. I'm fairly confident that even if you didn't do that it wouldn't make much of a difference, because the likelihood of anyone attempting to exploit your particular niche program are quite low. > But you go ahead and believe it's because of dumb luck if you like. I didn't say it was dumb luck. The fact of the matter is that most software isn't hardened in the way you describe, for simple economical reasons.
  - nineteen999 8y ago
    Sorry where is the non-sequitur? The previous poster purported that I mustn't have much "real world" experience in coding, and I responded that I and my team wouldn't be entrusted to successfully maintain a program and network that coordinates emergency services first responders over a large land mass and number of people if that was the case. If you honestly think that emergency services infrastructure is less of a valuable target to a rogue operator than Internet Widgets Inc. or whatever then I think we are done here for now. This is all a huge over-reaction to my initial point which was; the format that the OP proposed was busted, and any good C/C++ programmer should notice that immediately rather than implement it blindly. If they can't do that then, yes, definitely stick to a managed language. Which I agree is good advice anyway. Thank you and have a nice day.
    - zeroname 8y ago
      > Sorry where is the non-sequitur? It is in your original statement (abbreviated): If there were easily exploited buffer overflow in <our program>, ambulances and fire engines <for our customers> would never be called to their destinations nor arrive on time. One doesn't follow from the other. Your statement implies there are bad actors in existence that would actually exploit such flaws in order to disrupt the service. That may or may not be true, therefore it does not follow. > The previous poster purported that I mustn't have much "real world" experience in coding, and I responded that I and my team wouldn't be entrusted to successfully maintain a program and network that coordinates emergency services first responders over a large land mass and number of people if that was the case. That's not what I actually replied to, but it's also a non-sequitur. It would be entirely plausible that you could be a reckless band of cowboy coders that happens to be able to produce a working product that is nevertheless full of theoretically exploitable flaws that just happen to not get exploited, because nobody cares. Also, whoever "entrusted" you may themselves be entirely reckless or incompetent. I'm not saying that any of this is the case, I'm simply saying you can't logically deduce one from the other. Therefore it doesn't really work as an argument.
      - nineteen999 8y ago
        > One doesn't follow from the other. Your statement implies there are bad actors in existence that would actually exploit such flaws in order to disrupt the service. Rubbish. If the service in question was directly accessible from a public network and its source code known and published, it would be attacked in less than 5 minutes. That is the assumption that causes millions of dollars to be spent on securing the application and the environment every year. We are not prepared to take that risk, and we secure appropriately and expensively. > Also, whoever "entrusted" you may themselves be entirely reckless or incompetent. That is how employment works in the wider world of Internet Widgets etc. but not in critical government regulated infrastructure like emergency services. Yes we are unable to prove 100% that the application has no externally exploitable bugs, despite our best efforts, so we don't claim that it is and go and make it accessible to untrusted sources of input.
        8y ago

nineteen999 8y ago

Or maybe we know the program we inherited has flaws, and we don't connect it/publish its source code to the internet claiming it's fit for general purpose use, and we strive everyday to provide new mitigations and defense in depth to prevent its exploitation. But you go ahead and believe it's because of dumb luck if you like.

zeroname 8y ago
You made a simple If-this-then-that claim that was a non-sequitur, that's my only point. > we strive everyday to provide new mitigations and defense in depth to prevent its exploitation. I'm fairly confident that even if you didn't do that it wouldn't make much of a difference, because the likelihood of anyone attempting to exploit your particular niche program are quite low. > But you go ahead and believe it's because of dumb luck if you like. I didn't say it was dumb luck. The fact of the matter is that most software isn't hardened in the way you describe, for simple economical reasons.
- nineteen999 8y ago
  Sorry where is the non-sequitur? The previous poster purported that I mustn't have much "real world" experience in coding, and I responded that I and my team wouldn't be entrusted to successfully maintain a program and network that coordinates emergency services first responders over a large land mass and number of people if that was the case. If you honestly think that emergency services infrastructure is less of a valuable target to a rogue operator than Internet Widgets Inc. or whatever then I think we are done here for now. This is all a huge over-reaction to my initial point which was; the format that the OP proposed was busted, and any good C/C++ programmer should notice that immediately rather than implement it blindly. If they can't do that then, yes, definitely stick to a managed language. Which I agree is good advice anyway. Thank you and have a nice day.
  - zeroname 8y ago
    > Sorry where is the non-sequitur? It is in your original statement (abbreviated): If there were easily exploited buffer overflow in <our program>, ambulances and fire engines <for our customers> would never be called to their destinations nor arrive on time. One doesn't follow from the other. Your statement implies there are bad actors in existence that would actually exploit such flaws in order to disrupt the service. That may or may not be true, therefore it does not follow. > The previous poster purported that I mustn't have much "real world" experience in coding, and I responded that I and my team wouldn't be entrusted to successfully maintain a program and network that coordinates emergency services first responders over a large land mass and number of people if that was the case. That's not what I actually replied to, but it's also a non-sequitur. It would be entirely plausible that you could be a reckless band of cowboy coders that happens to be able to produce a working product that is nevertheless full of theoretically exploitable flaws that just happen to not get exploited, because nobody cares. Also, whoever "entrusted" you may themselves be entirely reckless or incompetent. I'm not saying that any of this is the case, I'm simply saying you can't logically deduce one from the other. Therefore it doesn't really work as an argument.
    - nineteen999 8y ago
      > One doesn't follow from the other. Your statement implies there are bad actors in existence that would actually exploit such flaws in order to disrupt the service. Rubbish. If the service in question was directly accessible from a public network and its source code known and published, it would be attacked in less than 5 minutes. That is the assumption that causes millions of dollars to be spent on securing the application and the environment every year. We are not prepared to take that risk, and we secure appropriately and expensively. > Also, whoever "entrusted" you may themselves be entirely reckless or incompetent. That is how employment works in the wider world of Internet Widgets etc. but not in critical government regulated infrastructure like emergency services. Yes we are unable to prove 100% that the application has no externally exploitable bugs, despite our best efforts, so we don't claim that it is and go and make it accessible to untrusted sources of input.
      - 8y ago