3 ms·

Why is it that vulnerabilities are almost unavoidable? I’m not trying to be a smart-ass; I’m an analyst at an MSP and I’m doing my first pen-test soon. I’m unde

Why is it that vulnerabilities are almost unavoidable? I’m not trying to be a smart-ass; I’m an analyst at an MSP and I’m doing my first pen-test soon. I’m under no illusions that my job title or growing responsibilities make me a security expert (or anywhere near it). Is it because the software stack is just too complex for network programmers to handle? (Not that router OSes are the only pieces of software that have vulnerabilities; and I imagine that you’d say that vulnerabilities are almost unavoidable in general.)

taormina 8y ago
Well, think about the number of abstractions on top of abstractions that make up all software. From the bits on the wire, being translated into binary, to machine, to higher-level languages. Then let's talk about frameworks on top of frameworks. Unless every contributor remembers every specific detail, edge-case, or assumption (and even if they manage to, we're still only human) then any mistake could potentially have disastrous ramifications. As bugs are unavoidable, you're going to have vulnerabilities. Vulnerabilities are just useful bugs. Now, of course, at least bothering with CYOA is expected in security, but is rarely implemented up to snuff.... But then again, security is a "cost center", no?
toomanyrichies 8y ago
I'm not an expert either, so take this with a grain of salt. At the risk of sounding glib, I'd think the biggest cause of this unavoidability is that security professionals have to be "right" (in the sense of plugging every hole) every time, whereas black-hats need to be right (in the sense of finding said vulnerabilities) only once (or a few times depending on the vector, but you get the idea). Being on a Blue Team strikes me as a hard, thankless job, and I'm grateful for the people who volunteer for it.
tetha 8y ago
In my book, the problem is that vulnerabilities are usually of two kinds - bugs or more specifically unintended and unexpected interactions between different subsystems. Bugs are like the use after free in a kernel modifying a little state, leading to ASLR circumvention leading to RCE. Unintended system interactions are bigger in my opinion, since they tend to combine bugs across systems, or they even combine multiple unintended system interactions into bigger and more complex unintended system interactions. These things grow wild - some of the things people do with meltdown, rowhammer are wild and just enable even crazier things. On a higher level, things like server side request forgery, dns rebound attacks to circumvent firewalls are powerful tools to make existing attacks more powerful. I'm no where near an expert, just an interested admin, but a lot of these mechanics are wild. Now where's the point to all that rambling? Point is, most software is written and grown in very uncontrolled ways. Software outside of aviation or the space sector is written to get done, and if bugs occur, they do occur. A lot of software systems are running huge stacks with massive components - again to get done - and no one is scrutinizing all of the interactions going on in there. With my product hat on, that's fine. Selling things is a good way to get paid. But from a security point of view, most software systems are just waiting to grow big enough until the right people care and it'll be ugly. This is also why I largely consider our application servers to be overly resource hungry remote shells. Puts me in the right mindset.
sathackr 8y ago
There is a saying "If someone can make it, someone can break it" This applies to physical security also. There are way too many attack vectors for you to plug every possible hole. 20 years ago do you think anyone was considering that you could determine the contents of memory otherwise inaccessible your process just by reading the memory accessible to you in certain manners (Rowhammer, [1]) Or that a device taped under your desk could read your encryption keys right out of the air? [2][3] Or that an attacker could intentionally cause errors by overclocking/undervolting "glitching" your device to cause it to skip certain instructions in order to gain access to it? [4][5][6] Or that exploiting flaws in the way a CPU tries to predict the next instructions could lead to privileged information leakage? [7] A sibling commenter hit the nail on the head. You have a large surface area to protect. They only need to find one tiny crack. But by far the most common vulnerabilities are simply someone not properly validating input[8][9][10]<-(a ton of specific attack incidents listed here), or not allocating memory properly [11] [1] https://en.wikipedia.org/wiki/Row_hammer https://en.wikipedia.org/wiki/Row_hammer [2] https://www.theregister.co.uk/2015/06/20/tempest_radioshack/ https://www.theregister.co.uk/2015/06/20/tempest_radioshack/ [3] https://www.tau.ac.il/~tromer/radioexp/ https://www.tau.ac.il/~tromer/radioexp/ [4] https://toothless.co/blog/bootloader-bypass-part1/ https://toothless.co/blog/bootloader-bypass-part1/ [5] https://av.tib.eu/media/32392 https://av.tib.eu/media/32392 [6] https://www.multichannel.com/news/black-sunday-fix-dbs-pirates-132341 https://www.multichannel.com/news/black-sunday-fix-dbs-pirat... [7] https://www.wired.com/story/foreshadow-intel-secure-enclave-vulnerability/ https://www.wired.com/story/foreshadow-intel-secure-enclave-... [8] https://www.pcworld.com/article/148007/security.html https://www.pcworld.com/article/148007/security.html [9] https://blog.detectify.com/2016/04/06/owasp-top-10-injection/ https://blog.detectify.com/2016/04/06/owasp-top-10-injection... [10] https://codecurmudgeon.com/wp/sql-injection-hall-of-shame/ https://codecurmudgeon.com/wp/sql-injection-hall-of-shame/ [11] https://engineering.purdue.edu/ResearchGroups/SmashGuard/BoF.html https://engineering.purdue.edu/ResearchGroups/SmashGuard/BoF...

taormina 8y ago

Well, think about the number of abstractions on top of abstractions that make up all software. From the bits on the wire, being translated into binary, to machine, to higher-level languages. Then let's talk about frameworks on top of frameworks. Unless every contributor remembers every specific detail, edge-case, or assumption (and even if they manage to, we're still only human) then any mistake could potentially have disastrous ramifications. As bugs are unavoidable, you're going to have vulnerabilities. Vulnerabilities are just useful bugs. Now, of course, at least bothering with CYOA is expected in security, but is rarely implemented up to snuff.... But then again, security is a "cost center", no?

toomanyrichies 8y ago

I'm not an expert either, so take this with a grain of salt. At the risk of sounding glib, I'd think the biggest cause of this unavoidability is that security professionals have to be "right" (in the sense of plugging every hole) every time, whereas black-hats need to be right (in the sense of finding said vulnerabilities) only once (or a few times depending on the vector, but you get the idea). Being on a Blue Team strikes me as a hard, thankless job, and I'm grateful for the people who volunteer for it.

tetha 8y ago

In my book, the problem is that vulnerabilities are usually of two kinds - bugs or more specifically unintended and unexpected interactions between different subsystems. Bugs are like the use after free in a kernel modifying a little state, leading to ASLR circumvention leading to RCE. Unintended system interactions are bigger in my opinion, since they tend to combine bugs across systems, or they even combine multiple unintended system interactions into bigger and more complex unintended system interactions. These things grow wild - some of the things people do with meltdown, rowhammer are wild and just enable even crazier things. On a higher level, things like server side request forgery, dns rebound attacks to circumvent firewalls are powerful tools to make existing attacks more powerful. I'm no where near an expert, just an interested admin, but a lot of these mechanics are wild. Now where's the point to all that rambling? Point is, most software is written and grown in very uncontrolled ways. Software outside of aviation or the space sector is written to get done, and if bugs occur, they do occur. A lot of software systems are running huge stacks with massive components - again to get done - and no one is scrutinizing all of the interactions going on in there. With my product hat on, that's fine. Selling things is a good way to get paid. But from a security point of view, most software systems are just waiting to grow big enough until the right people care and it'll be ugly. This is also why I largely consider our application servers to be overly resource hungry remote shells. Puts me in the right mindset.

sathackr 8y ago

There is a saying "If someone can make it, someone can break it" This applies to physical security also. There are way too many attack vectors for you to plug every possible hole. 20 years ago do you think anyone was considering that you could determine the contents of memory otherwise inaccessible your process just by reading the memory accessible to you in certain manners (Rowhammer, [1]) Or that a device taped under your desk could read your encryption keys right out of the air? [2][3] Or that an attacker could intentionally cause errors by overclocking/undervolting "glitching" your device to cause it to skip certain instructions in order to gain access to it? [4][5][6] Or that exploiting flaws in the way a CPU tries to predict the next instructions could lead to privileged information leakage? [7] A sibling commenter hit the nail on the head. You have a large surface area to protect. They only need to find one tiny crack. But by far the most common vulnerabilities are simply someone not properly validating input[8][9][10]<-(a ton of specific attack incidents listed here), or not allocating memory properly [11] [1] https://en.wikipedia.org/wiki/Row_hammer https://en.wikipedia.org/wiki/Row_hammer [2] https://www.theregister.co.uk/2015/06/20/tempest_radioshack/ https://www.theregister.co.uk/2015/06/20/tempest_radioshack/ [3] https://www.tau.ac.il/~tromer/radioexp/ https://www.tau.ac.il/~tromer/radioexp/ [4] https://toothless.co/blog/bootloader-bypass-part1/ https://toothless.co/blog/bootloader-bypass-part1/ [5] https://av.tib.eu/media/32392 https://av.tib.eu/media/32392 [6] https://www.multichannel.com/news/black-sunday-fix-dbs-pirates-132341 https://www.multichannel.com/news/black-sunday-fix-dbs-pirat... [7] https://www.wired.com/story/foreshadow-intel-secure-enclave-vulnerability/ https://www.wired.com/story/foreshadow-intel-secure-enclave-... [8] https://www.pcworld.com/article/148007/security.html https://www.pcworld.com/article/148007/security.html [9] https://blog.detectify.com/2016/04/06/owasp-top-10-injection/ https://blog.detectify.com/2016/04/06/owasp-top-10-injection... [10] https://codecurmudgeon.com/wp/sql-injection-hall-of-shame/ https://codecurmudgeon.com/wp/sql-injection-hall-of-shame/ [11] https://engineering.purdue.edu/ResearchGroups/SmashGuard/BoF.html https://engineering.purdue.edu/ResearchGroups/SmashGuard/BoF...