Well, so, I think that McFeters makes the point that he's trying to change the behavior of companies. If they look at this differently, then the adjustments will be made. You mention that "Vulnerabilities aren't defects unless the behavior of the application is inconsistent with it's requirements."
I'd love to think that SQL Injection vulns are inconsistent with it's requirements.
What McFeters is talking about is not just rewarding or punishing developers, it's about changing the stance of an organization as a whole. Basically just what you are asking for.
You're looking at discovery of flaws at the wrong point... as most do. If you constantly find flaws by hiring pentest firms, you are in the wrong stage. You need to get Secure SDLC built into your development and actually try to catch these flaws in the design phase. This will considerably lower the cost and number of vulnerabilities.
I think that McFeters would agree with you, probably except for the part where you call him a "clueless writer dork". This is more often than not a symptom of the culture of a company, not of the developers. If you read McFeters' whole article, he comments on creating a more positive culture that rewards developers who catch bugs, etc.
This is the perfect example of why a lot of companies need a reality check. You can't hold devs under the fire for flaws that were introduced by the original design itself, which more often than not is driven by flawed business requirements.
I work with the vulnerability management team and product security team at a large software company, and trust me vulnerabilities are treated as product defects. The cost of addressing vulnerabilities in the field is huge, and not addressing them is simply not feasible - customers would never tolerate it.
Haha, then you must not work for Apple or Microsoft.
Seriously though, I think that McFeters is pointing out that in his experience, companies are not treating them as defects, and he also points to an article by Dave Goldsmith that shows some companies are still not treating them at all.
We've treated potential vulnerabilities in our products, even extremely minor ones, as defects for over two decades now. And we have always given them very high priority.
To the best of our knowledge we've never had a remote exploit vulnerability, but even so we've gone so far as to scrap thousands of freshly pressed CDs a day before releasing them because I spotted a way to get root access through a tricky bit of business with shared libraries. (And that was for something spotted internally - no customer ever reported it.)
The real question isn't whether to treat security vulnerabilities as a defect - of course you do - but - somewhat paradoxically - whether or not to treat them as security vulnerabilities. We were acquired some time ago and have now adopted (and adapted to) various more complex procedures typical of a large company. There's this little box you're supposed to check in our current bug reporting system that says "this is a security vulnerability". The problem is that checking that box fires up a whole lot of extra process that rarely helps and can actually hinder prompt resolution of the problem and getting the fix into customer's hands.
From your standpoint, your company treats vulnerabilities as defects. I think the author (McFeters) is making the point that most companies do not. Since he does work as a consultant for Ernst & Young, and has many times mentioned his background with web application pen testing, I think it's safe to say he probably has a pretty good grasp on how many do treat vulns as defects and how many don't.
I'm curious though, if your company treats vulns as defects, then do you punish or praise employees as the author suggests you should? Has your company implemented the much talked about Secure SDLC to catch vulns in the design phase?
Where exactly did they tell everyone to not use Safari?
In fact, I believe that MS reported the vulnerability to Apple and helped them understand why it needs to be fixed.
Surely I am. I get tired of fighting arguments about who's OS is better. It really doesn't matter, the point is that there's a security issue.
My understanding is that IE has had a patch released, but I could be wrong on that, but either way it is on the way.
Apple has "fixed" the Safari Carpet Bomb issue, but Rios has said that it is still not truly fixed and that there is still ways to place files in predictable locations.
This came in communication with the author of the original article.
Again, Microsoft can't prevent bugs in other people's software. That's why this problem is complex. If you'll notice, it isn't IE that gets tricked into pulling down malicious content and dumping it into a predictable location.
SO they did fix it. Open your fucking eyes. The blended flaw with IE is already fixed. Now theirs a blended flaw with Safari and Firefox. M$ can't fix Apple's shitty code on their OS.
Yeah, so the problem is, M$ is fine until Safari and FF come on and don't sanitize shit. They rely to much on the OS to do shit for them, and then it makes M$ look bad. This IS an Apple flaw. The exploit path involves the use of either IE or FF. The reason it's not vulnerable on Apple is cause Apple devs don't write quite as shitty code for the Mac as they do for Windows.
Well, but this is the hard part of the argument. See, when Microsoft develops its own system, it does so in a certain way. When M$ designs IE, they make it fit that system. Since they have more knowledge, they can prevent things like this from happening in their own softwares. Of course, when third-parties develop for that system, they don't have that intimate knowledge, so they may assume that Windows protects them, when really they need to protect themselves.
The "blended" threat really creates some "Who's fault is it anyways" questions.
Rios may have a DIFFERENT way of placing files onto the desktop, or a DIFFERENT leverage point for the Carpet Bomb attack that becomes useful when using FF 2/3.
It is hard to understand, the fact that it is a "blended" attack with two different browsers yields a lot of possibilities. Until Rios releases details, we'll have to speculate.
It's not just that though. You make great points that an advanced user can likely find a work around for some issues and SHOULD have the right to fix an issue if possible (thus requiring full disclosure).
The other thing to consider here, a lot of vendors are in the freaking prehistoric period when it comes to addressing issues. Originally, Apple decided NOT to fix this issue, because you could only put executable content on a user's desktop. I mean, by itself, that's still a big issue. When vendors take these approaches, it becomes easier for researchers to just drop an 0-day.
So, there's a couple of issues here. The first is that you can place files on the user's desktop. This IS (or at least was) Safari's problem. All it takes is crafting a file that has an icon that looks like IE or your recycle bin, or whatever else and someone double-clicks to getting owned.
The second issue becomes the blended attack. So using Safari to place the file, then something else to kick the file off. This is where IE originally came in, but Microsoft patched that, then now we have FF 2/3.
I would not be surprised to see Opera have similar blended issues.
So, the whole point is that our systems are becoming more complex with all of the options out there that are available to us. These interactions can lead to unexpected security issues.
Slashdot Mirror
bad ass
Well, so, I think that McFeters makes the point that he's trying to change the behavior of companies. If they look at this differently, then the adjustments will be made. You mention that "Vulnerabilities aren't defects unless the behavior of the application is inconsistent with it's requirements."
I'd love to think that SQL Injection vulns are inconsistent with it's requirements.
What McFeters is talking about is not just rewarding or punishing developers, it's about changing the stance of an organization as a whole. Basically just what you are asking for.
You're looking at discovery of flaws at the wrong point... as most do. If you constantly find flaws by hiring pentest firms, you are in the wrong stage. You need to get Secure SDLC built into your development and actually try to catch these flaws in the design phase. This will considerably lower the cost and number of vulnerabilities.
I think that McFeters would agree with you, probably except for the part where you call him a "clueless writer dork". This is more often than not a symptom of the culture of a company, not of the developers. If you read McFeters' whole article, he comments on creating a more positive culture that rewards developers who catch bugs, etc.
This is the perfect example of why a lot of companies need a reality check. You can't hold devs under the fire for flaws that were introduced by the original design itself, which more often than not is driven by flawed business requirements.
SecureThroughObscure
Good to see a response from the original author on this. Awitod, don't confuse a difference of opinion with lack of experience.
I work with the vulnerability management team and product security team at a large software company, and trust me vulnerabilities are treated as product defects. The cost of addressing vulnerabilities in the field is huge, and not addressing them is simply not feasible - customers would never tolerate it.
Haha, then you must not work for Apple or Microsoft.
Seriously though, I think that McFeters is pointing out that in his experience, companies are not treating them as defects, and he also points to an article by Dave Goldsmith that shows some companies are still not treating them at all.
SecureThroughObscure
We've treated potential vulnerabilities in our products, even extremely minor ones, as defects for over two decades now. And we have always given them very high priority. To the best of our knowledge we've never had a remote exploit vulnerability, but even so we've gone so far as to scrap thousands of freshly pressed CDs a day before releasing them because I spotted a way to get root access through a tricky bit of business with shared libraries. (And that was for something spotted internally - no customer ever reported it.) The real question isn't whether to treat security vulnerabilities as a defect - of course you do - but - somewhat paradoxically - whether or not to treat them as security vulnerabilities. We were acquired some time ago and have now adopted (and adapted to) various more complex procedures typical of a large company. There's this little box you're supposed to check in our current bug reporting system that says "this is a security vulnerability". The problem is that checking that box fires up a whole lot of extra process that rarely helps and can actually hinder prompt resolution of the problem and getting the fix into customer's hands.
From your standpoint, your company treats vulnerabilities as defects. I think the author (McFeters) is making the point that most companies do not. Since he does work as a consultant for Ernst & Young, and has many times mentioned his background with web application pen testing, I think it's safe to say he probably has a pretty good grasp on how many do treat vulns as defects and how many don't.
I'm curious though, if your company treats vulns as defects, then do you punish or praise employees as the author suggests you should? Has your company implemented the much talked about Secure SDLC to catch vulns in the design phase?
SecureThroughObscure
Where exactly did they tell everyone to not use Safari? In fact, I believe that MS reported the vulnerability to Apple and helped them understand why it needs to be fixed.
Surely I am. I get tired of fighting arguments about who's OS is better. It really doesn't matter, the point is that there's a security issue. My understanding is that IE has had a patch released, but I could be wrong on that, but either way it is on the way. Apple has "fixed" the Safari Carpet Bomb issue, but Rios has said that it is still not truly fixed and that there is still ways to place files in predictable locations. This came in communication with the author of the original article.
Again, Microsoft can't prevent bugs in other people's software. That's why this problem is complex. If you'll notice, it isn't IE that gets tricked into pulling down malicious content and dumping it into a predictable location.
Damn, that's the most genius comment on Slashdot all year.
SO they did fix it. Open your fucking eyes. The blended flaw with IE is already fixed. Now theirs a blended flaw with Safari and Firefox. M$ can't fix Apple's shitty code on their OS.
Yeah, so the problem is, M$ is fine until Safari and FF come on and don't sanitize shit. They rely to much on the OS to do shit for them, and then it makes M$ look bad. This IS an Apple flaw. The exploit path involves the use of either IE or FF. The reason it's not vulnerable on Apple is cause Apple devs don't write quite as shitty code for the Mac as they do for Windows.
Well, you're getting off track here. You can comment on how M$ should make their APIs more clear... but your comments are pretty off base.
Well, but this is the hard part of the argument. See, when Microsoft develops its own system, it does so in a certain way. When M$ designs IE, they make it fit that system. Since they have more knowledge, they can prevent things like this from happening in their own softwares. Of course, when third-parties develop for that system, they don't have that intimate knowledge, so they may assume that Windows protects them, when really they need to protect themselves. The "blended" threat really creates some "Who's fault is it anyways" questions.
Rios may have a DIFFERENT way of placing files onto the desktop, or a DIFFERENT leverage point for the Carpet Bomb attack that becomes useful when using FF 2/3. It is hard to understand, the fact that it is a "blended" attack with two different browsers yields a lot of possibilities. Until Rios releases details, we'll have to speculate.
It's not just that though. You make great points that an advanced user can likely find a work around for some issues and SHOULD have the right to fix an issue if possible (thus requiring full disclosure). The other thing to consider here, a lot of vendors are in the freaking prehistoric period when it comes to addressing issues. Originally, Apple decided NOT to fix this issue, because you could only put executable content on a user's desktop. I mean, by itself, that's still a big issue. When vendors take these approaches, it becomes easier for researchers to just drop an 0-day.
So, there's a couple of issues here. The first is that you can place files on the user's desktop. This IS (or at least was) Safari's problem. All it takes is crafting a file that has an icon that looks like IE or your recycle bin, or whatever else and someone double-clicks to getting owned. The second issue becomes the blended attack. So using Safari to place the file, then something else to kick the file off. This is where IE originally came in, but Microsoft patched that, then now we have FF 2/3. I would not be surprised to see Opera have similar blended issues. So, the whole point is that our systems are becoming more complex with all of the options out there that are available to us. These interactions can lead to unexpected security issues.
Ahahahhahaa Man, you guys are extra hilarious tonight.
Maybe I'm a Star Trek geek, but that was hilarious!
Hee hee hee, comeon, you can be more creative than that... I just saw a commercial for Viagra, there's got to be a tie together joke there.