SA Security BloggersPopular EntriesArticles How-To's Papers Tools Neologisms SSLCertificate fingerprints: SHA1: 61 13 45 4B 4C F9 89 9B B7 87 C8 78 F7 38 12 CB 07 E2 60 BF HTTPS version. LicenseDisclaimer
This blog and its contents are in no way affiliated with, or endorsed by my employer.
|
Random Entry: Virgin Territory
< Debian (and derivatives) OpenSSL-based keys vulnerability | Roberto of WabiSabiLabi Responds > Thursday, May 15. 2008Why I think Exploit Markets are bad - a response to Roberto Preatoni of WabiSabiLabiComments
Display comments as
(Linear | Threaded)
Thank you Dominic for your appraisal of the Preatoni talk. I agree with many of your assertions and I am also not associated with any security vendor.
Security Practitioners should to be discerning and introspective with regard to their actions. A good rule of thumb is to ask oneself the question: "Will the actions that I am about to take make things more or less secure?" If the answer is the latter, then it needs to be treated with circumspection.
Unfortunately, in Preatoni's mind, the criminal cracker euphamistically becomes a "security researcher", much the same as a whore becoming a "Sex Care Worker".
Preatoni is simply a cheeky thug who advocates his actions by transferring the focus to the vendors. Not that they are angels, but this kind of advocacy strategy is well known amongst the worst criminals. Even on his dying day, AL Capone believed that he was a "good guy" who provided amply for his employees and made many men wealthy.
There is good reason for the US Army to be in the "top ten" visitors to his "marketplace". They have a cell in Guantánamo Bay with his name on it.
PS: You were not the only one with your hand up.
Hey Julius,
Thanks for the support. I've heard a few people say they had their hands up too, so I apologise for my statement.
However, I'm not sure if I agree with the idea that all vulnerability research is a criminal activity. Take David Litchfield as an example. His good work is what pushed Oracle security forward by a couple of decades, and I'd argue he was *too* careful about it. For example, he waited 3 years before he disclosed one bug Oracle hadn't fixed.
Also, please be careful of name calling, it tends to turn these sorts of discussions into fights.
On your point about the US army, and Roberto's about IDS signatures. It is interesting to note that Microsoft gives the Air Force copies of their patches before anyone else in the world. Given that a patch can be reverse engineered to an exploit (more reliably than an IDS sig can) - Halvar Flake did it in 20min with his BinDiff plugin - this potentially gives the US .mil monthly 0days and a large cyber-offensive capability.
P.S. Psalm 37 is a nice one, thanks.
--->"...I'm not sure if I agree with the idea that all vulnerability research is a criminal activity."
Hmm, I don't recall stating that. (Reads response again.) No, I did not state that all vulnerability research is a criminal activity. My only reference to the word "criminal" was when I described the state of mind that euphamizes criminal activity by obfuscating facts. It's quite a common state of mind, actually -- hence my reference to Capone.
---> "Also, please be careful of name calling, it tends to turn these sorts of discussions into fights."
Touché. I have a tendency to be outspoken on matters that I feel strongly about, and tend to call a spade a spade. Then again, this is your blog and I'll respect your rules.
---> "... this potentially gives the US .mil monthly 0days and a large cyber-offensive capability."
Agreed on the facts, however I am undecided on whether this is a good thing or not.
Hello, Dominic, the power of Google brought me here.
I am Roberto Preatoni, and yes, I was also surprised to see that you were the only one raising your hand. To be honest, I was curios to see "who was that guy" and to hear his motivations eventually opening up a discussion thread.
We can do it here, that's the beauty of the Internet.
Point by point, as you wrote:
The All Knowing Market
We should distinguish between the world as we would all wish to see and the real world. In an utopian world, famine and diseases are solved by humanitarian-driven actions. In the real world, everything is tighten to money. I know it's not nice, but that's the way it is. And if it is in that way, it's just because the world it's driven by us humans. Do doubt my dog, being it in power, would choose to drive the world under the flag of justice and ethics.
Vendors held ransom
I agree, the market competition eventually will hold vendors ransom. But again, in a free market-driven approach, when the vulnerability's price paid by the vendors will be pushed so high, it might be the proper time for them to decide to invest the appropriate amount of money and efforts in security research and development.
And that's the natural conclusion of all the discussion: the vendors should carry on ALL the costs related to their product security. Period.
Black Market
No matter what we will do, what actions we will take, there will always be a black market, ready to pay high prices for vulnerabilities. We must live with that, it's just ethical dreams against pragmatism.
Weaponization.
As I said in the conference, the easiest way to weaponize a vulnerability is to buy a IDS/IPS and to some reverse engineering work.
Let's put it in this way:
Responsible vendors = secure software = no patches = no weaponization
Up to that point, no practical discussion can hold security researchers responsible for the eventual weaponization of their findings. It's like if you tell me that the mining industry should account responsibility because somebody used a knife made with its metal, to stab someone's back.
Arbitrary restrictions:
You made a mistake. We do allow web app vulnerabilities in our marketplace (in fact, we had several listed in the past). What we do not allow, is a vulnerability related to a specific online service (website) as that info could not be useful to the general public or legitimate penetration testers, but would harm directly the website and it would be interesting only for those who have criminal intents.
A better way.
Another mistake. We, in fact, do not apply the responsible disclosure policy, as ZDI. We provide just a marketplace. It's up to the security researchers whether to disclose it or not to the vendor, we just comply to his directives.
Vulnerability research prize fund.
Here I might agree as an alternative model to compensate researcher's efforts, but only if the prize would be paid by the software vendors and if the prize would be hefty, not just some peanuts as it used to be in similar initiatives. An example? The prize given by the Mozilla foundation for a new vulnerability under its Bug Bounty contest: 500$ and a laptop bag. Excuse me, sir.
Best regards,
Roberto Preatoni
PS to Julius Francis
You statement: "Unfortunately, in Preatoni's mind, the criminal cracker euphamistically becomes a "security researcher", much the same as a whore becoming a "Sex Care Worker"." was delightful. The whole security researchers category is now pleased to know that they are just "criminal crackers". So kind of you, cheers.
Ciao Robert,
I'm so glad you found your way here. The internet is indeed a wonderful place. I tried to find you at the conference to have this chat face to face, but this will have to do.
Jumping straight into it, let me respond:
The all knowing market
----------------------
I realise money is king, but being able to apply hindsight to ensure the money is spent in the best way on the best outcomes is what I am advocating. Not creating a market for a market's sake (although I don't believe that's what you're doing.)
Vendors held ransom
-------------------
But that's the problem. It isn't really a free market if the buyer isn't willing, and are forced into buying it. Additionally, the high price will need to be paid in addition to any security work they do, making smaller vendors less likely to be able to afford it. Finally, there is already a way to force vendors to invest in security work, full disclosure. It has worked well in the past (although not ideally).
Weaponisation
-------------
I don't believe IDS/IPS signatures are that easy to weaponise. Very few instances will allow a few bits of packet info to fully reveal an exploit. At best it could point out where to look for a bug, but it is unlikely we will see automated exploits generated from IPS signatures.
Arbitrary restrictions
----------------------
Thanks for elaborating on your criteria. However, if you are worried about affecting one merchant, why are you not worried about potentially affect many? As the only difference between a bug that exploits a single vendor vs. a bug that exploits a platform in this sense is the affected population? Also, this still doesn't address my main point of this section, that the restriction is arbitrary when put next to the principles of a 'free market' and leads to the sorts of inconsistencies I've just pointed out.
A better way
------------
I agree that there are large differences between ZDI and yourselves. But in terms of disclosure there isn't much, because anyone who buys the bug can keep it secret. A vendor who buys it can refuse to ever disclose it potentially leaving us as users vulnerable like the used to before the good ol days of full disclosure.
The fund
--------
I'm still rolling the idea of the fund around in my mind. There are a variety of ways it could be funded, and I agree the price would need to be large enough to incentivise real research. I would love you to look through it and give your thoughts, as you're probably the best person to.
That's about it. Thanks for the reply, and we hope to see you in SA again soon. We'll make you some proper putanesca ;)
Vendors held ransom
-------------------
--->"But that's the problem. It isn't really a free market if the buyer isn't willing, and are forced into buying it. Additionally, the high price will need to be paid in addition to any security work they do, making smaller vendors less likely to be able to afford it."
Here you fall in some contradictions. The same full disclosure was enforced because it was clear that NO VENDOR was willingly put any effort in patching the holes. Let's not forget this problem, which is the very foundation of the whole insecurity issue.
--->"Finally, there is already a way to force vendors to invest in security work, full disclosure. It has worked well in the past (although not ideally)."
Which means, security researchers should work for free to force the vendors to produce patches. See, the beauty of the WSL project is that it doesn't want to replace the current models, it just want to be an alternative. If a security researcher wants to comply to the full disclosure policy instead of referring to our marketplace, we praise his choice and we support it. I personally did it in the past and I know some researchers that, depending from case to case, might decide to go for the full disclosure process or to go through our market.
They are free, they have a free will and we respect it.
Weaponisation
-------------
--->"I don't believe IDS/IPS signatures are that easy to weaponise. Very few instances will allow a few bits of packet info to fully reveal an exploit. At best it could point out where to look for a bug, but it is unlikely we will see automated exploits generated from IPS signatures."
Uhmm... the guys here at WSL's laboratory smiled a bit ;)
Arbitrary restrictions
----------------------
--->"Thanks for elaborating on your criteria. However, if you are worried about affecting one merchant, why are you not worried about potentially affect many? As the only difference between a bug that exploits a single vendor vs. a bug that exploits a platform in this sense is the affected population? Also, this still doesn't address my main point of this section, that the restriction is arbitrary when put next to the principles of a 'free market' and leads to the sorts of inconsistencies I've just pointed out."
Once again, you are referring to merchants, we are referring to software producers. Two different categories.
A better way
------------
--->"I agree that there are large differences between ZDI and yourselves. But in terms of disclosure there isn't much, because anyone who buys the bug can keep it secret. A vendor who buys it can refuse to ever disclose it potentially leaving us as users vulnerable like the used to before the good ol days of full disclosure."
An example: a security researcher places his findings on WSL's marketplace. WSL ask him wheter he wants the vendor to be notified or not. The researchers chooses to notify the vendor. Still, his exploit is on the marketplace and me, as a security penetration tester, I might want to buy it to offer services to my clients, because I know that the vendor will take some time to produce a patch therefore i'll have a time window to market my services, even if the hole was disclosed to the vendor. Make sense?
The fund
--------
--->"I'm still rolling the idea of the fund around in my mind. There are a variety of ways it could be funded, and I agree the price would need to be large enough to incentivise real research. I would love you to look through it and give your thoughts, as you're probably the best person to."
I certainly will.
How about this: what about a law, who forces software vendors, to set a certain percentage of their incomes generated by software sales to be given to such "security funds"?
After all, whenever you buy an insurance policy for your car, the insurance company is forced by law to set part of their incomes to be used to purchase stocks or real estate, as a guarantee fund for the policy subscribers.
--->"That's about it. Thanks for the reply, and we hope to see you in SA again soon. We'll make you some proper putanesca ;)
Excuse me, I'll cook with pleasure for ya'll.
--->Here you fall in some contradictions. The same full disclosure was enforced because it was clear that NO VENDOR was willingly put any effort in patching the holes. Let's not forget this problem, which is the very foundation of the whole insecurity issue.
Sure, but given that we have full disclosure, why introduce another alternative that has potentially worse outcomes?
--->Which means, security researchers should work for free to force the vendors to produce patches. See, the beauty of the WSL project is that it doesn't want to replace the current models, it just want to be an alternative. If a security researcher wants to comply to the full disclosure policy instead of referring to our marketplace, we praise his choice and we support it. I personally did it in the past and I know some researchers that, depending from case to case, might decide to go for the full disclosure process or to go through our market.
They are free, they have a free will and we respect it.
I agree with you here, it is an alternative, and no-one is forced to use it. However, I am discussing the implications of if it were to 'take off' as WSL seems to be. As for researchers working for free, like I said in the original blog entry, I think there are ways that valuable research can be monetised without needing to trade the potentially dangerous good to the highest bidder.
--->Uhmm... the guys here at WSL's laboratory smiled a bit ;)
I am not saying it will never work. Take for example, SQL slammer, a generous examples where the IDS signature gives away the bug. However, to turn that into an exploit you still need to merge the payload and bug into something clever. But as you move onto more complex things, your ability to even discern the exploit can become difficult. Taken to an extreme case, you don't get IDS signatures for local privilege escalation, let alone an ability to reverse engineer it.
Although, I'm prepared to admit that you may have evidence to prove me wrong, can we see it ;)
--->Once again, you are referring to merchants, we are referring to software producers. Two different categories.
Merchants buy software from software produces. By implication a bug in that software affects all merchants. A bug in a merchants software affects only one merchant.
software producer sploit population > merchant sploit population
To use an analogy. If I sell a way to break into your house, someone can use it to break into your house. Whereas if I sell a way to break into door type x1, someone can use it to break into all houses with door type x1. It is inconsistent to sell one and not the other. Although, I admit you are more likely to get sued for selling merchant sploits.
--->An example: a security researcher places his findings on WSL's marketplace. WSL ask him wheter he wants the vendor to be notified or not. The researchers chooses to notify the vendor. Still, his exploit is on the marketplace and me, as a security penetration tester, I might want to buy it to offer services to my clients, because I know that the vendor will take some time to produce a patch therefore i'll have a time window to market my services, even if the hole was disclosed to the vendor. Make sense?
Thanks, that does make sense. I didn't realise you allowed the researcher to choose for the bug to be disclosed to the vendor and still be sold. Doesn't that reduce the value significantly though? My gut feel is that ticking the 'disclose to vendor' box would so badly reduce the price of the vulnerability, that people are incentivised not to?
--->"I'm still rolling the idea of the fund around in my mind. There are a variety of ways it could be funded, and I agree the price would need to be large enough to incentivise real research. I would love you to look through it and give your thoughts, as you're probably the best person to."
--->I certainly will.
How about this: what about a law, who forces software vendors, to set a certain percentage of their incomes generated by software sales to be given to such "security funds"?
After all, whenever you buy an insurance policy for your car, the insurance company is forced by law to set part of their incomes to be used to purchase stocks or real estate, as a guarantee fund for the policy subscribers.
Could work. I don't see legislators going for it though, but I do believe that 'percentage of income' is a better way to ensure security than balanced scorecards.
--->Excuse me, I'll cook with pleasure for ya'll.
I look forward to it.
|
Quicksearchthis blog: Security Blogs |
Tracked: Feb 05, 11:23