6 ms·

Why do we still write insecure software?

64 points by luu 11y ago

Animats 11y ago
We write insecure software because the costs of insecure software do not fall on the companies selling it.
cwyers 11y ago
> (Sidebar: It is a common misconception in the programming world for some reason that the adage "It's a poor craftsman that blames his tools." means that someone blaming their tools proves they are a poor workman. The true meaning of the phrase is that it is a poor craftsman that has bad tools in the first place. A skilled craftsman does not use a dull saw without complaint. They get or make a sharp one, without complaint. A craftsman who uses poor tools without complaint is even poorer than the one who is at least complaining!) This is fantastic.
deleted 11y ago
[deleted]
Natanael_L 11y ago
Define what's secure first. Any unintended behavior can become a security flaw, and there will always be unintended behavior in anything complex.
- cwyers 11y ago
  He actually addresses this.
- deleted 11y ago
  [deleted]
legulere 11y ago
> int8(100) + int8(100) = -56 is just one possible answer. Signed integer overflow depends on signed integer representation in go (it's undefined for unsigned integers in C): https://golang.org/ref/spec#Integer_overflow https://golang.org/ref/spec#Integer_overflow So the SafeAddInt8 in the blogpost may not be correct on architectures that use really strange representations. Lots of C developers that wanted to make their code safer ran into a related trap in C. There it's totally undefined and the compiler may just throw the check out all together. I wonder why Go doesn't just define signed integers to be in 2's complement representation. Are there any architectures out there that use something else for integers?
- agwa 11y ago
  > (it's undefined for unsigned integers in C): No, unsigned integer overflow is defined to wrap around in C. Only signed integer overflow is undefined. > I wonder why Go doesn't just define signed integers to be in 2's complement representation It does: "The value of an n-bit integer is n bits wide and represented using two's complement arithmetic" (from https://golang.org/ref/spec#Numeric_types https://golang.org/ref/spec#Numeric_types)
  - legulere 11y ago
    You're right, I wanted to write signed integers. I wonder what they mean with representation in the spec then?
- spc476 11y ago
  More so, using 'JO' (jump overflow) after every signed operation isn't that expensive, speedwise (branch prediction for the win) but it does make the code larger. http://boston.conman.org/2015/09/07.1 http://boston.conman.org/2015/09/07.1
  - GeorgeTirebiter 11y ago
    Wouldn't this sort of thing be better handled by an exception? The CPU should help us more to write better secure software.
    - spc476 11y ago
      It would, but the x86 doesn't trap on signed overflow. There is an INTO instruction (interrupt on signed overflow) but you have to include it after every signed instruction, and when I tested that, it was apparent that INTO is not a "fast instruction". Also, under Linux, when INTO fires, it is interpreted as a SIGSEGV. Not what I was expecting.
xyzzy123 11y ago
The first thing to fix is bad tooling, yes, but it's not the whole picture. Once all your queries are safe by default, your languages have memory safety, your templates XSS-encode by default etc etc (this is basically the situation at most sane workplaces) - there are still security issues. There are fewer security issues left, but they're gnarlier. What we see now are "application logic" and business logic issues. Overflow and language-level sharp edges exist, but these are a small proportion of the mistakes developers (in particular, web application) seem to be making. Situations where the server unintentionally signs user-controlled data, bad OAuth2 flows, missing or incorrect authorisation checks, accepting data from the client as "validated" - these are much more common in my experience. The other interesting thing I've noticed is that when developers who are used to "safe by default" frameworks have to step outside the framework for any reason (e.g. front-end is 90% angular, but 10% "bespoke" JS) they will make mistakes with very high likelihood. The solution is tooling yes, but also education and process.
- zzzcpan 11y ago
  I think such security issues are similar to the ones author described. They require decent language-level abstractions to disappear as well. Some sort of lightweight processes to deal with trust boundaries explicitly and easily.
  - Natanael_L 11y ago
    What you'd need is almost dynamic live proof checkers hooked to your IDE capable of tracking the effects of code changes / refactoring to do that, linked to test cases themselves carrying proofs of testing the spec completely. How else will you be guaranteed to catch Goto Fail and similar? What's worse is when you hit the issue of "composability" in cryptography - two servers run different algorithms making different assumptions, and when they interact the assumptions fail to translate and neither provide the guarantee they should. Like cross-protocol attacks, such as when one server becomes a signing oracle for another. Edit: and beyond that, we have cross architecture disagreement on results of calculations intended to be deterministic. Like how SPARC Bitcoin Qt binaries previously would have had the Bitcoin reward schedule loop every 255 years and go back to 50 coins per block and restarting the countdown.
NickHaflinger 11y ago
Because the underlying hardware MMU can't prevent one process from accessing memory that don't belong to it.
CM30 11y ago
No mention of the obvious answer here; because coders have jobs, employers and lives. Hence a lot of the time, code has to be written quickly and the company usually doesn't give a toss whether something's been done the 'right' way... so long as it works. If you've got a deadline in thirty minutes, you're probably not going to try and do everything the best possible way. Same deal if you've got a family or friends to get back to, an event to go or anything else that requires you to get things done quickly. You're rewarded more for getting things done quickly than you are getting them done properly or securely. When your client wants their site or program done as quickly as possible for a low cost, or your startup needs to 'move fast and break things'... security will usually suffer in the process.
- jacquesm 11y ago
  > so long as it works. That's what I call the 'happy path fallacy'. If code performs along the happy path, then great, move fast, break things and release. Never mind that outside the happy path there are tons of issues, bugs, things never even looked at until they suddenly are found to be the root cause of a major breach. Those parts do not get the attention they need because there is no direct economic incentive to do so. Software is not at all done when it 'works'. It's only done when it works well for all input and there are no unknown paths of execution that lead to unexpected results. It's pretty rare for a codebase with more than a few 100 lines to be completely known to such a level that there isn't a way to cause it to do something the author did not intend to be there. Complexity is a very bad enemy in that respect and code tends to get extremely complex and hard to reason about if you don't have iron discipline during the design process.
- TheAndruu 11y ago
  To add to this, coders frequently have managers who don't allow time to test and improve much beyond what works, even when asked for.
  - collyw 11y ago
    Exactly! It is often that the coders are the ones pushing to do thing more correctly, but mnagemnt wants the latest feature out.
Mindless2112 11y ago
> Whether you want an exception or an error or some sort of Either/Option type or whatever depends on your language, but something ought to twitch here. The problem with handling integer overflow is that the mechanisms for it are clunky. Is there a programming language that handles integer overflow using a better mechanism than those listed? (I mean without resorting to a BigNum.)
jacquesm 11y ago
There is actually a very simple answer to this question: We have 100's of implementations of roughly the same thing instead of just 1 implementation that is made bulletproof. Every new framework, every new HTTP server, every new language will cause another round of re-implementation and will cause yet another round of the same old bugs and security problems.
- wernercd 11y ago
  The problem with "the same thing that's made bullet proof": What defines bullet proof and how is that "perfect" solution going to work for all different business types? Obligatory XKCD: https://xkcd.com/927/ https://xkcd.com/927/
  - jacquesm 11y ago
    Bullet proof would at least mean that we no longer have these infinite series of regressions, that what is fixed stays fixed. And 'obligatory xkcd's rarely are and I wished people would stop posting them as a way to settle an argument without being receptive to the core idea of that argument. The word 'standard' never was on my mind, merely a way to get things implemented properly once rather than re-implemented over and over again. How many HTML server components are there, in C alone? Then all the java ones, the ruby ones, the Go ones and all the other languages. Then all the crypto libraries and all their re-implementations and so on. There has to be a better way to do code re-use and to avoid the NIH syndrome that seems to be one of the major generators behind all these re-implementations of roughly the same thing. But it's so much easier to start again, rather than to delve into an existing code base, extend it properly and document it. There is little glory in a minor contribution to a much larger project. Starting over means it's your project, you get to be the big wheel and when you lose interest we have one more Swiss cheese to contend with.
    - wernercd 11y ago
      Of course there is a better way... but the issue is: How are you going to make others use your way? How are you going to fund replacing the DECADES of existing tech? The XKCD puts it perfectly... you create a better way - and God knows, there has to be many better ways than say JavaScript or PHP - how are you going to MAKE people switch? Your better way - assuming it is perfect - is still crowded out and unable to gain any traction. I mean... ANYTHING that gets made gets a "format war". What makes you think Google, IBM, Microsoft, Apple, etc would all agree on something long enough to make that happen? We can't even get a new DVD format without years of fighting... What's perfect for Google (which revolves around Search) won't necessarily work for Microsoft (Which revolves around Server and Office)... Or Apple (Which revolves around... Magic?)... Or... What language should they all agree on? What "bullet proof" product will meet all their needs? What style of programming does everything everyone needs? You can't create that "perfect" solution, because people and companies that have such a massively different wants, needs and goals... That's why things such as TDD, Modular code, Code reviews, etc all matter so much more than the specific platform you are on...
ratsimihah 11y ago
Because software is meant to be written by computers, not humans.
philip142au 11y ago
Its really simple, my boss said I have to have done in 3 weeks what takes 3 months.
amai 11y ago
Stop complaining and use Ada or https://en.wikipedia.org/wiki/SPARK_%28programming_language%29 https://en.wikipedia.org/wiki/SPARK_%28programming_language%.... There is also a web Server in Ada: http://libre.adacore.com/tools/aws/ http://libre.adacore.com/tools/aws/

64 points by luu 11y ago

We write insecure software because the costs of insecure software do not fall on the companies selling it.

> (Sidebar: It is a common misconception in the programming world for some reason that the adage "It's a poor craftsman that blames his tools." means that someone blaming their tools proves they are a poor workman. The true meaning of the phrase is that it is a poor craftsman that has bad tools in the first place. A skilled craftsman does not use a dull saw without complaint. They get or make a sharp one, without complaint. A craftsman who uses poor tools without complaint is even poorer than the one who is at least complaining!) This is fantastic.

deleted 11y ago

[deleted]

Natanael_L 11y ago

Define what's secure first. Any unintended behavior can become a security flaw, and there will always be unintended behavior in anything complex.

cwyers 11y ago
He actually addresses this.
deleted 11y ago
[deleted]

legulere 11y ago

> int8(100) + int8(100) = -56 is just one possible answer. Signed integer overflow depends on signed integer representation in go (it's undefined for unsigned integers in C): https://golang.org/ref/spec#Integer_overflow https://golang.org/ref/spec#Integer_overflow So the SafeAddInt8 in the blogpost may not be correct on architectures that use really strange representations. Lots of C developers that wanted to make their code safer ran into a related trap in C. There it's totally undefined and the compiler may just throw the check out all together. I wonder why Go doesn't just define signed integers to be in 2's complement representation. Are there any architectures out there that use something else for integers?

agwa 11y ago
> (it's undefined for unsigned integers in C): No, unsigned integer overflow is defined to wrap around in C. Only signed integer overflow is undefined. > I wonder why Go doesn't just define signed integers to be in 2's complement representation It does: "The value of an n-bit integer is n bits wide and represented using two's complement arithmetic" (from https://golang.org/ref/spec#Numeric_types https://golang.org/ref/spec#Numeric_types)
- legulere 11y ago
  You're right, I wanted to write signed integers. I wonder what they mean with representation in the spec then?
spc476 11y ago
More so, using 'JO' (jump overflow) after every signed operation isn't that expensive, speedwise (branch prediction for the win) but it does make the code larger. http://boston.conman.org/2015/09/07.1 http://boston.conman.org/2015/09/07.1
- GeorgeTirebiter 11y ago
  Wouldn't this sort of thing be better handled by an exception? The CPU should help us more to write better secure software.
  - spc476 11y ago
    It would, but the x86 doesn't trap on signed overflow. There is an INTO instruction (interrupt on signed overflow) but you have to include it after every signed instruction, and when I tested that, it was apparent that INTO is not a "fast instruction". Also, under Linux, when INTO fires, it is interpreted as a SIGSEGV. Not what I was expecting.

xyzzy123 11y ago

The first thing to fix is bad tooling, yes, but it's not the whole picture. Once all your queries are safe by default, your languages have memory safety, your templates XSS-encode by default etc etc (this is basically the situation at most sane workplaces) - there are still security issues. There are fewer security issues left, but they're gnarlier. What we see now are "application logic" and business logic issues. Overflow and language-level sharp edges exist, but these are a small proportion of the mistakes developers (in particular, web application) seem to be making. Situations where the server unintentionally signs user-controlled data, bad OAuth2 flows, missing or incorrect authorisation checks, accepting data from the client as "validated" - these are much more common in my experience. The other interesting thing I've noticed is that when developers who are used to "safe by default" frameworks have to step outside the framework for any reason (e.g. front-end is 90% angular, but 10% "bespoke" JS) they will make mistakes with very high likelihood. The solution is tooling yes, but also education and process.

zzzcpan 11y ago
I think such security issues are similar to the ones author described. They require decent language-level abstractions to disappear as well. Some sort of lightweight processes to deal with trust boundaries explicitly and easily.
- Natanael_L 11y ago
  What you'd need is almost dynamic live proof checkers hooked to your IDE capable of tracking the effects of code changes / refactoring to do that, linked to test cases themselves carrying proofs of testing the spec completely. How else will you be guaranteed to catch Goto Fail and similar? What's worse is when you hit the issue of "composability" in cryptography - two servers run different algorithms making different assumptions, and when they interact the assumptions fail to translate and neither provide the guarantee they should. Like cross-protocol attacks, such as when one server becomes a signing oracle for another. Edit: and beyond that, we have cross architecture disagreement on results of calculations intended to be deterministic. Like how SPARC Bitcoin Qt binaries previously would have had the Bitcoin reward schedule loop every 255 years and go back to 50 coins per block and restarting the countdown.

NickHaflinger 11y ago

Because the underlying hardware MMU can't prevent one process from accessing memory that don't belong to it.

CM30 11y ago

No mention of the obvious answer here; because coders have jobs, employers and lives. Hence a lot of the time, code has to be written quickly and the company usually doesn't give a toss whether something's been done the 'right' way... so long as it works. If you've got a deadline in thirty minutes, you're probably not going to try and do everything the best possible way. Same deal if you've got a family or friends to get back to, an event to go or anything else that requires you to get things done quickly. You're rewarded more for getting things done quickly than you are getting them done properly or securely. When your client wants their site or program done as quickly as possible for a low cost, or your startup needs to 'move fast and break things'... security will usually suffer in the process.

jacquesm 11y ago
> so long as it works. That's what I call the 'happy path fallacy'. If code performs along the happy path, then great, move fast, break things and release. Never mind that outside the happy path there are tons of issues, bugs, things never even looked at until they suddenly are found to be the root cause of a major breach. Those parts do not get the attention they need because there is no direct economic incentive to do so. Software is not at all done when it 'works'. It's only done when it works well for all input and there are no unknown paths of execution that lead to unexpected results. It's pretty rare for a codebase with more than a few 100 lines to be completely known to such a level that there isn't a way to cause it to do something the author did not intend to be there. Complexity is a very bad enemy in that respect and code tends to get extremely complex and hard to reason about if you don't have iron discipline during the design process.
TheAndruu 11y ago
To add to this, coders frequently have managers who don't allow time to test and improve much beyond what works, even when asked for.
- collyw 11y ago
  Exactly! It is often that the coders are the ones pushing to do thing more correctly, but mnagemnt wants the latest feature out.

Mindless2112 11y ago

> Whether you want an exception or an error or some sort of Either/Option type or whatever depends on your language, but something ought to twitch here. The problem with handling integer overflow is that the mechanisms for it are clunky. Is there a programming language that handles integer overflow using a better mechanism than those listed? (I mean without resorting to a BigNum.)

jacquesm 11y ago

There is actually a very simple answer to this question: We have 100's of implementations of roughly the same thing instead of just 1 implementation that is made bulletproof. Every new framework, every new HTTP server, every new language will cause another round of re-implementation and will cause yet another round of the same old bugs and security problems.

wernercd 11y ago
The problem with "the same thing that's made bullet proof": What defines bullet proof and how is that "perfect" solution going to work for all different business types? Obligatory XKCD: https://xkcd.com/927/ https://xkcd.com/927/
- jacquesm 11y ago
  Bullet proof would at least mean that we no longer have these infinite series of regressions, that what is fixed stays fixed. And 'obligatory xkcd's rarely are and I wished people would stop posting them as a way to settle an argument without being receptive to the core idea of that argument. The word 'standard' never was on my mind, merely a way to get things implemented properly once rather than re-implemented over and over again. How many HTML server components are there, in C alone? Then all the java ones, the ruby ones, the Go ones and all the other languages. Then all the crypto libraries and all their re-implementations and so on. There has to be a better way to do code re-use and to avoid the NIH syndrome that seems to be one of the major generators behind all these re-implementations of roughly the same thing. But it's so much easier to start again, rather than to delve into an existing code base, extend it properly and document it. There is little glory in a minor contribution to a much larger project. Starting over means it's your project, you get to be the big wheel and when you lose interest we have one more Swiss cheese to contend with.
  - wernercd 11y ago
    Of course there is a better way... but the issue is: How are you going to make others use your way? How are you going to fund replacing the DECADES of existing tech? The XKCD puts it perfectly... you create a better way - and God knows, there has to be many better ways than say JavaScript or PHP - how are you going to MAKE people switch? Your better way - assuming it is perfect - is still crowded out and unable to gain any traction. I mean... ANYTHING that gets made gets a "format war". What makes you think Google, IBM, Microsoft, Apple, etc would all agree on something long enough to make that happen? We can't even get a new DVD format without years of fighting... What's perfect for Google (which revolves around Search) won't necessarily work for Microsoft (Which revolves around Server and Office)... Or Apple (Which revolves around... Magic?)... Or... What language should they all agree on? What "bullet proof" product will meet all their needs? What style of programming does everything everyone needs? You can't create that "perfect" solution, because people and companies that have such a massively different wants, needs and goals... That's why things such as TDD, Modular code, Code reviews, etc all matter so much more than the specific platform you are on...

ratsimihah 11y ago

Because software is meant to be written by computers, not humans.

philip142au 11y ago

Its really simple, my boss said I have to have done in 3 weeks what takes 3 months.

amai 11y ago

Stop complaining and use Ada or https://en.wikipedia.org/wiki/SPARK_%28programming_language%29 https://en.wikipedia.org/wiki/SPARK_%28programming_language%.... There is also a web Server in Ada: http://libre.adacore.com/tools/aws/ http://libre.adacore.com/tools/aws/