8 ms·

“Security problems are primarily just bugs”

119 points by peterhunt 9y ago

partycoder 9y ago
Security problems are bugs, sure. But a different kind. Security is a non-functional requirement. In an analogy with construction, each room is a functional requirement, and non-functional requirements are the materials you used to build, which can be considered some sort of quality attribute. And just like in construction, if after building a house you are given more strict seismic requirements, fire prevention, etc... you might need to rebuild the entire house.
- dfox 9y ago
  Large class of security problems are also functional bugs in the sense that valid input causes incorrect behavior or should not be accepted as valid. This includes most instances of XSS and many instances of SQLI or buffer overflows.
  - lostboys67 9y ago
    Nope the largest class of security problems are caused by the Users
- pessimizer 9y ago
  Is a room any more a functional requirement than security? A roof keeps the rain off, walls keep the wind out and keep things private, but rooms are more containers than requirements. And if closing a door at the right angle causes the roof to fall in, that's a failure of function.
  - qznc 9y ago
    My understanding of functional requirement is that it is binary. Function is either there or not. A non-functional requirement can sometimes be measured, but not in a yes or no fashion. For example, frames per second is non-functional. Things are no secure or insecure in general, thus non-functional. You can turn non-functional into function requirement if you specify a boundary. For example, a 60 frames per second requirement is functional. For security, you can require "secure under certain attacker models" to make it functional. Example: Is Signal communication secure, if you assume the attacker can only read data on the server? There is an answer and it is probably "no". That does not mean, Signal is secure in general. An attacker which can access your phone breaks the security. (It is also not really binary, because someone might find a hole somewhere in the future, but for practical purposes, we can assume the crypto holds)
    - alanfranzoni 9y ago
      > My understanding of functional requirement is that it is binary Not so easy. 1) Very often (too often) functional requirements are poorly worded, and they leave things open to interpretation or to implied meanings. Example: "as user Foo, when authenticated in I should be able to open and modify all the documents I own, so that I can amend them". Does such user story look good? Probably; but it says nothing about the "contrasting" stories. A lot of times there won't be a story that says... "as user Foo, when non-authenticated I shouldn't be able to see any document by anybody". or "as user Foo, I should be able to see and modify my documents and only my documents" so if a non-authenticated user or a different user has access to your docs, you aren't probably breaking a functional requirements, but it's probably not how the system was meant to behave by most stakeholders. 2) Very often the functional requirements are OK for the sweet spot, but break on corner cases; so many people just won't notice what's wrong.
    - deleted 9y ago
      [deleted]
    - provost 9y ago
      > Things are no secure or insecure in general, thus non-functional. I would disagree with this assertion. A really common phrase in the infosec community is that "Security is not binary"
      - fusiongyro 9y ago
        Are you literate? Go back and reread the first sentence of the comment you are replying to.
  - partycoder 9y ago
    There are varying degrees of precipitation and wind speed that a roof can support. Those can vary and can be specified as requirements as well.
jph 9y ago
Linus advocates: 1) first do no harm to the kernel. 2) better to phase in warnings and fixes, rather than enforce a panic. 3) there's sufficient track record of security in practice. This sounds fully reasonable to me. If you're an OS builder and prefer an immediate-panic hardened system, then catch the warnings. Linux kernel post: http://lkml.iu.edu/hypermail/linux/kernel/1711.2/01701.html http://lkml.iu.edu/hypermail/linux/kernel/1711.2/01701.html
scandox 9y ago
> Despite his unreasonable tone, Linus is a hugely reasonable person. Is this a legitimate leadership technique? I mean I presume the intention is to have a kind of megaphone which will get the attention of a widely dispersed, highly independent group of people. The ultimate cat herding weapon. On the other hand I find it really unpleasant and feel like there must be better ways.
- rhaps0dy 9y ago
  >Is this a legitimate leadership technique? Perhaps it is for the Finnish. Check out "management by perkele" https://infogalactic.com/info/Management_by_perkele https://infogalactic.com/info/Management_by_perkele https://en.wikipedia.org/wiki/Finnish_profanity#perkele https://en.wikipedia.org/wiki/Finnish_profanity#perkele
  - lostboys67 9y ago
    A system designed to bully a mainly conscript army doesn't really work in the work place :-) This approach also doesn't work in modern professional armies note that from the beginning SF Troops (starting with the SAS) are very informal.
  - watwut 9y ago
    There is no direct command nor "swift decision making over prolonged pondering of many alternatives before making a decision" in that quote. All it is is calling people fucking morons in (most likely) hope that they are less likely argue back if arguing makes you a moron instead of someone engaging in meritocratic open discussion. I don't really mind people swearing, but attempts to frame that as something noble when it is nothing but emotions targetting argumentation technique are ridiculous.
  - tree_of_item 9y ago
    I really hate this excuse. "Oh, it's okay that he's an asshole, he's European!!"
    - geofft 9y ago
pjmlp 9y ago
> Also, since most security people aren't developers, they are also a bit clueless how things actually work. Bounds-checking, which they define as purely a security feature to stop buffer-overflows is actually overwhelmingly a debugging feature. Developers know this, security "experts" tend not to. These kernel changes were made by security people who failed to understand this, who failed to realize that their changes would uncover lots of bugs in existing code, and that killing buggy code was hugely inappropriate. Sorry, but I completely disagree here. Many of us that care about security are developers that have to clean up the mess of such ideas. And to once more paraphrase Hoare's Turing award speech. "Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
- geofft 9y ago
  Yeah, I am extremely confused at this, too. I am a developer by profession who happens to care about security because I care about delivering a good product. I'm not a "security person." Bounds-checking is a way for me to deliver a good product, and killing buggy code is sort of my job. Bounds-checking should be enabled in production.
  - ryandrake 9y ago
    One size does not fit all. Any debugging safety net will have a cost in terms of performance, and you usually have to pay that cost regardless of whether your code has bugs. It's why we don't release debug builds to customers or use them in production. If it is vital to your application to detect a certain kind of bug in production, then turn the checking on in production and pay the cost. Maybe it is not vital to my application or my application does not have these bugs. In my case it would be needless to pay the cost. To me, essential to delivering a good product is detecting and killing defective code before delivery. I recognize however, that this attitude is becoming more and more old fashioned.
hguhghuff 9y ago
Well yes in hindsight of course.
vog 9y ago
This strongly reminds me of the famous paper by Daniel J. Bernstein: "Some thoughts on security after ten years of qmail 1.0" https://cr.yp.to/qmail/qmailsec-20071101.pdf https://cr.yp.to/qmail/qmailsec-20071101.pdf
- deleted 9y ago
  [deleted]
- oftenwrong 9y ago
  I found a txt version of this: http://ondoc.logand.com/d/721/txt http://ondoc.logand.com/d/721/txt It's a bit easier for me to read without a fixed page layout.
qaq 9y ago
Considering that large number of breaches are through social engineering that statement is largely off.
mtgx 9y ago
I guess this is why Google is doing the right thing by working on its own microkernel. Similarly for Grsec guys, who forked Linux. Fundamental difference of opinions like these is why forks should happen in the open source world. I would like to see someone do a "LibreSSL" version of the Linux kernel, by cleaning it up of all the unneeded legacy cruft, modernizing its architecture, and making it more secure. I imagine only someone like Google (for servers, Chrome OS, and Android) or Microsoft (cloud services) could take on such a project, but of course they could only lead such a project. They would also need an alliance of partners to support the project. However, if they are committed to it and serious about making it way better from a security point of view, I could see many companies jumping ship from Linux Classic, especially in the automotive and IoT worlds, also also from web hosting world, and so on. Alternatively, perhaps the large companies could start supporting Rust OS/kernels such as Redox.
ryangittins 9y ago
I am also in whole-hearted agreement with Linus, here. In fact, I ran into this just recently. I discovered one of our systems at work actually stored encrypted passwords rather than just hashed ones, and decrypted it for validation. Yuck! Of course, I put a fix and a database migration in place as soon as I could and all is well now, but this worries me. It worries me because it must have been done out of ignorance (bad) or intentionally (worse) and billed as a feature or something. Neither of these things are mere bugs. This gaping flaw wasn't introduced by accident.
- baby 9y ago
  Note that a hash is not enough, you need a password hash (or some people call that phash, whatever). Argon2 is currently the recommendation to do such things.
- thisisit 9y ago
  Or maybe incomplete understanding of the system. I had lobby for a year to get even a simple encrypted passwords. "Why do we need encrypted passwords behind a corporate firewall?" they asked. That sucked all the energy out of me. So when they wrote a script to run a db extract, get all company salary data in csv and share it with literally 50+ people I gave up. Getting them to even encrypt data seemed impossible.
  - ryangittins 9y ago
    Oh geez, that's nuts. That's like asking, "Why do I need to put my valuables in a safe if I have a lock on my front door?"
    - scruple 9y ago
      > That's like asking, "Why do I need to put my valuables in a safe if I have a lock on my front door?" Not the GP, but I've experienced similar things during my career, and these sorts of analogies tend to work really well when explaining technical points to non-technical (and, sadly, even "technical") people.
bagswatchesus 9y ago
Because it is grotesquely insulting to the highly intelligent - http://www.handbagsjd.com/hermes http://www.handbagsjd.com/hermes
alanfranzoni 9y ago
Another, similar, take, from ALE2014: https://docs.google.com/presentation/d/1rXyl_YF-0lg3W8yY9mSo4UaoUrEWo8hKAng-GsF9XeI/pub?start=false&loop=false&delayms=3000#slide=id.g376b8bd03_011 https://docs.google.com/presentation/d/1rXyl_YF-0lg3W8yY9mSo... Security problems are, first and foremost, about CORRECTNESS. If you find an issue, most probably something has been done in an incorrect way by somebody who didn't really understand something. It's much harder to find out some security bug which is not a functional bug (for some part of the domain, not just the sweet spot). Of course that doesn't really apply to C or C++, where it's easy to do dumb mistakes by chance.
jstewartmobile 9y ago
DJB's approach to the problem: "Nowadays I am much more insistent on programming language support for smaller-scale partitioning, sane bounds checking, automatic updates of “summary” variables (e.g., “the number of nonzero elements of this array”), etc. By “sane bounds checking” I don’t mean what people normally mean by “bounds checking,” namely raising an exception if an index is out of range; what I mean is automatic array extension on writes, and automatic zero-fill on reads. (Out of memory? See Section 4.2.) Doing the same work by hand is silly"[0] [0] https://cr.yp.to/qmail/qmailsec-20071101.pdf https://cr.yp.to/qmail/qmailsec-20071101.pdf

119 points by peterhunt 9y ago

Security problems are bugs, sure. But a different kind. Security is a non-functional requirement. In an analogy with construction, each room is a functional requirement, and non-functional requirements are the materials you used to build, which can be considered some sort of quality attribute. And just like in construction, if after building a house you are given more strict seismic requirements, fire prevention, etc... you might need to rebuild the entire house.

dfox 9y ago
Large class of security problems are also functional bugs in the sense that valid input causes incorrect behavior or should not be accepted as valid. This includes most instances of XSS and many instances of SQLI or buffer overflows.
- lostboys67 9y ago
  Nope the largest class of security problems are caused by the Users
pessimizer 9y ago
Is a room any more a functional requirement than security? A roof keeps the rain off, walls keep the wind out and keep things private, but rooms are more containers than requirements. And if closing a door at the right angle causes the roof to fall in, that's a failure of function.
- qznc 9y ago
  My understanding of functional requirement is that it is binary. Function is either there or not. A non-functional requirement can sometimes be measured, but not in a yes or no fashion. For example, frames per second is non-functional. Things are no secure or insecure in general, thus non-functional. You can turn non-functional into function requirement if you specify a boundary. For example, a 60 frames per second requirement is functional. For security, you can require "secure under certain attacker models" to make it functional. Example: Is Signal communication secure, if you assume the attacker can only read data on the server? There is an answer and it is probably "no". That does not mean, Signal is secure in general. An attacker which can access your phone breaks the security. (It is also not really binary, because someone might find a hole somewhere in the future, but for practical purposes, we can assume the crypto holds)
  - alanfranzoni 9y ago
    > My understanding of functional requirement is that it is binary Not so easy. 1) Very often (too often) functional requirements are poorly worded, and they leave things open to interpretation or to implied meanings. Example: "as user Foo, when authenticated in I should be able to open and modify all the documents I own, so that I can amend them". Does such user story look good? Probably; but it says nothing about the "contrasting" stories. A lot of times there won't be a story that says... "as user Foo, when non-authenticated I shouldn't be able to see any document by anybody". or "as user Foo, I should be able to see and modify my documents and only my documents" so if a non-authenticated user or a different user has access to your docs, you aren't probably breaking a functional requirements, but it's probably not how the system was meant to behave by most stakeholders. 2) Very often the functional requirements are OK for the sweet spot, but break on corner cases; so many people just won't notice what's wrong.
  - deleted 9y ago
    [deleted]
  - provost 9y ago
    > Things are no secure or insecure in general, thus non-functional. I would disagree with this assertion. A really common phrase in the infosec community is that "Security is not binary"
    - fusiongyro 9y ago
      Are you literate? Go back and reread the first sentence of the comment you are replying to.
- partycoder 9y ago
  There are varying degrees of precipitation and wind speed that a roof can support. Those can vary and can be specified as requirements as well.

jph 9y ago

Linus advocates: 1) first do no harm to the kernel. 2) better to phase in warnings and fixes, rather than enforce a panic. 3) there's sufficient track record of security in practice. This sounds fully reasonable to me. If you're an OS builder and prefer an immediate-panic hardened system, then catch the warnings. Linux kernel post: http://lkml.iu.edu/hypermail/linux/kernel/1711.2/01701.html http://lkml.iu.edu/hypermail/linux/kernel/1711.2/01701.html

scandox 9y ago

> Despite his unreasonable tone, Linus is a hugely reasonable person. Is this a legitimate leadership technique? I mean I presume the intention is to have a kind of megaphone which will get the attention of a widely dispersed, highly independent group of people. The ultimate cat herding weapon. On the other hand I find it really unpleasant and feel like there must be better ways.

rhaps0dy 9y ago
>Is this a legitimate leadership technique? Perhaps it is for the Finnish. Check out "management by perkele" https://infogalactic.com/info/Management_by_perkele https://infogalactic.com/info/Management_by_perkele https://en.wikipedia.org/wiki/Finnish_profanity#perkele https://en.wikipedia.org/wiki/Finnish_profanity#perkele
- lostboys67 9y ago
  A system designed to bully a mainly conscript army doesn't really work in the work place :-) This approach also doesn't work in modern professional armies note that from the beginning SF Troops (starting with the SAS) are very informal.
- watwut 9y ago
  There is no direct command nor "swift decision making over prolonged pondering of many alternatives before making a decision" in that quote. All it is is calling people fucking morons in (most likely) hope that they are less likely argue back if arguing makes you a moron instead of someone engaging in meritocratic open discussion. I don't really mind people swearing, but attempts to frame that as something noble when it is nothing but emotions targetting argumentation technique are ridiculous.
- tree_of_item 9y ago
  I really hate this excuse. "Oh, it's okay that he's an asshole, he's European!!"
  - geofft 9y ago

pjmlp 9y ago

> Also, since most security people aren't developers, they are also a bit clueless how things actually work. Bounds-checking, which they define as purely a security feature to stop buffer-overflows is actually overwhelmingly a debugging feature. Developers know this, security "experts" tend not to. These kernel changes were made by security people who failed to understand this, who failed to realize that their changes would uncover lots of bugs in existing code, and that killing buggy code was hugely inappropriate. Sorry, but I completely disagree here. Many of us that care about security are developers that have to clean up the mess of such ideas. And to once more paraphrase Hoare's Turing award speech. "Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."

geofft 9y ago
Yeah, I am extremely confused at this, too. I am a developer by profession who happens to care about security because I care about delivering a good product. I'm not a "security person." Bounds-checking is a way for me to deliver a good product, and killing buggy code is sort of my job. Bounds-checking should be enabled in production.
- ryandrake 9y ago
  One size does not fit all. Any debugging safety net will have a cost in terms of performance, and you usually have to pay that cost regardless of whether your code has bugs. It's why we don't release debug builds to customers or use them in production. If it is vital to your application to detect a certain kind of bug in production, then turn the checking on in production and pay the cost. Maybe it is not vital to my application or my application does not have these bugs. In my case it would be needless to pay the cost. To me, essential to delivering a good product is detecting and killing defective code before delivery. I recognize however, that this attitude is becoming more and more old fashioned.

hguhghuff 9y ago

Well yes in hindsight of course.

vog 9y ago

This strongly reminds me of the famous paper by Daniel J. Bernstein: "Some thoughts on security after ten years of qmail 1.0" https://cr.yp.to/qmail/qmailsec-20071101.pdf https://cr.yp.to/qmail/qmailsec-20071101.pdf

deleted 9y ago
[deleted]
oftenwrong 9y ago
I found a txt version of this: http://ondoc.logand.com/d/721/txt http://ondoc.logand.com/d/721/txt It's a bit easier for me to read without a fixed page layout.

qaq 9y ago

Considering that large number of breaches are through social engineering that statement is largely off.

mtgx 9y ago

I guess this is why Google is doing the right thing by working on its own microkernel. Similarly for Grsec guys, who forked Linux. Fundamental difference of opinions like these is why forks should happen in the open source world. I would like to see someone do a "LibreSSL" version of the Linux kernel, by cleaning it up of all the unneeded legacy cruft, modernizing its architecture, and making it more secure. I imagine only someone like Google (for servers, Chrome OS, and Android) or Microsoft (cloud services) could take on such a project, but of course they could only lead such a project. They would also need an alliance of partners to support the project. However, if they are committed to it and serious about making it way better from a security point of view, I could see many companies jumping ship from Linux Classic, especially in the automotive and IoT worlds, also also from web hosting world, and so on. Alternatively, perhaps the large companies could start supporting Rust OS/kernels such as Redox.

ryangittins 9y ago

I am also in whole-hearted agreement with Linus, here. In fact, I ran into this just recently. I discovered one of our systems at work actually stored encrypted passwords rather than just hashed ones, and decrypted it for validation. Yuck! Of course, I put a fix and a database migration in place as soon as I could and all is well now, but this worries me. It worries me because it must have been done out of ignorance (bad) or intentionally (worse) and billed as a feature or something. Neither of these things are mere bugs. This gaping flaw wasn't introduced by accident.

baby 9y ago
Note that a hash is not enough, you need a password hash (or some people call that phash, whatever). Argon2 is currently the recommendation to do such things.
thisisit 9y ago
Or maybe incomplete understanding of the system. I had lobby for a year to get even a simple encrypted passwords. "Why do we need encrypted passwords behind a corporate firewall?" they asked. That sucked all the energy out of me. So when they wrote a script to run a db extract, get all company salary data in csv and share it with literally 50+ people I gave up. Getting them to even encrypt data seemed impossible.
- ryangittins 9y ago
  Oh geez, that's nuts. That's like asking, "Why do I need to put my valuables in a safe if I have a lock on my front door?"
  - scruple 9y ago
    > That's like asking, "Why do I need to put my valuables in a safe if I have a lock on my front door?" Not the GP, but I've experienced similar things during my career, and these sorts of analogies tend to work really well when explaining technical points to non-technical (and, sadly, even "technical") people.

bagswatchesus 9y ago

Because it is grotesquely insulting to the highly intelligent - http://www.handbagsjd.com/hermes http://www.handbagsjd.com/hermes

alanfranzoni 9y ago

Another, similar, take, from ALE2014: https://docs.google.com/presentation/d/1rXyl_YF-0lg3W8yY9mSo4UaoUrEWo8hKAng-GsF9XeI/pub?start=false&loop=false&delayms=3000#slide=id.g376b8bd03_011 https://docs.google.com/presentation/d/1rXyl_YF-0lg3W8yY9mSo... Security problems are, first and foremost, about CORRECTNESS. If you find an issue, most probably something has been done in an incorrect way by somebody who didn't really understand something. It's much harder to find out some security bug which is not a functional bug (for some part of the domain, not just the sweet spot). Of course that doesn't really apply to C or C++, where it's easy to do dumb mistakes by chance.

jstewartmobile 9y ago

DJB's approach to the problem: "Nowadays I am much more insistent on programming language support for smaller-scale partitioning, sane bounds checking, automatic updates of “summary” variables (e.g., “the number of nonzero elements of this array”), etc. By “sane bounds checking” I don’t mean what people normally mean by “bounds checking,” namely raising an exception if an index is out of range; what I mean is automatic array extension on writes, and automatic zero-fill on reads. (Out of memory? See Section 4.2.) Doing the same work by hand is silly"[0] [0] https://cr.yp.to/qmail/qmailsec-20071101.pdf https://cr.yp.to/qmail/qmailsec-20071101.pdf