From roman at rs-labs.com Thu Oct 1 14:33:46 2009 From: roman at rs-labs.com (Roman Medina-Heigl Hernandez) Date: Thu, 01 Oct 2009 20:33:46 +0200 Subject: [Dailydave] Rooted CON 2010 - CFP Message-ID: <4AC4F60A.5060904@rs-labs.com> =============================== - Rooted CON 2010 - C A L L F O R P A P E R S =============================== .: [ ABOUT ] Rooted CON is a Security Congress to be held in Madrid (Spain) on March 2010. Our goal is to promote security by offering highly technical talks with a practical approach (interesant mix of theory / demos) and neutrality (although we want businesses/enterprises to participate in the congress, they should prioritize the technical and objective approach). We also want people to participate and enjoy... And even come back home with a prize! Therefore, we will hold various events (apart from talks), one of the most important of them being the CTF ("Capture the flag") contest, with substantial cash prizes and been designed by none other than one of the "Sexy Pandas" (finalist team in the traditional "Defcon" CTF). And of course if you are brave enough you will also have fun by living the beautiful nights of Madrid... .: [ FORMAT ] We would like to receive two kind of proposals: - fast talks. Duration: 20'. - normal talks. Duration: 50'. If you have a crazy/interesting and fresh idea that could be summarized in fewer time, please don't hesitate and submit a fast talk. If your idea is even crazier and need more time to be explained in depth, use the second one: normal talk. We are only accepting submissions in Spanish and English language. We will do our best to have simultaneous translation in the conference room but we cannot promise it since it will depend on budget and sponsors. .: [ TOPICS ] Every hot topic in the security market is welcome. These are only some examples: - innovative defensive and offensive techniques. - everything related to fraud, phishing, trojan horses in financial entities, protection mechanisms and technologies... - "reversing", low-level techniques, kernel, ... - vulnerabilities discovery, "fuzzing" and related topics. - virtual contexts attacks, clusters, "cloud computing" and new "in the cloud" products. - cryptography and cryptanalysis. - mobile security. - hacking tools: custom developments. - document security. - VoIP, phreaking, ... - forensics / antiforensics. - wireless security. - steganography and covert channels. - web applications security - ... .: [ SUBMISSION PROCEDURE ] Would you like to speak at Rooted CON? Please, don't forget to make talks illustrative and include demos! :) Please, send your application via e-mail to: cfp -AT- rootedcon.es For the talk to be accepted in the initial selection process it should comply with the previously described format and *must* include *all* the following info: - title - author (full name and optionally nick/handle) - bio (some lines defining who you are) - duration (normal or fast talk?) - abstract (should be sufficiently extensive for being correctly evaluated) - location/nationality - facilities needed - do you plan to present same or similar talk in another conference? Which one? .: [ SCHEDULE ] October 1, 2009 - CFP opens. December 20, 2009 - CFP closes. December 31, 2009 - Speakers selected. January 10, 2010 - Final paper and presentation material submitted. .: [ SPEAKER PRIVILEGES ] Speakers will be given the following benefits: - Free accommodation. - Free access to the conference. - Travel expenses (if possible). - Free party tickets/drinks. .: [ SPONSORS ] There are still opportunities to help us in organizing the best security congress in Spain while obtaining an interesting marketing ROI. If you are interested in being one of our sponsors, please, contact us at: sponsors -AT- rootedcon.es .: [ LINKS ] - Web site http://www.rootedcon.es/ - Facebook group http://www.facebook.com/group.php?gid=96410924798 - LinkedIn group http://www.linkedin.com/groups?gid=1969438 - Announce mailing-list https://listas.rootedcon.es/mailman/listinfo/rooted-announce -=EOF=- -- Rooted CON staff From dave at immunityinc.com Tue Oct 6 10:12:40 2009 From: dave at immunityinc.com (dave) Date: Tue, 06 Oct 2009 10:12:40 -0400 Subject: [Dailydave] Exploits matter. Message-ID: <4ACB5058.7070503@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I spent some time after yesterday's CANVAS release, which included the SMBv2 CANVAS exploit (Release note here: https://forum.immunityinc.com/board/thread/39/canvas-release-6-51/ ) looking at exploit statistics. Like Morpheus, I wanted to put some numbers on a feeling you may have been having. That feeling is this: Exploits against Windows are hard now. It takes an average of 3 person-months per exploit now. That's a long time. Or in other words, that's a lot of money. But if you are like me, you are thinking "But it's still worth it". And here's why: Without exploits, you have no way to know what matters. Or, more realistically, what doesn't matter. I.E. in this case, 64 bit computers are not going to be exploited with SMBv2 any time soon, of at all. Since enterprises skipped Vista and use 64 bit for their Windows 2008 servers, SMBv2 didn't hurt as badly as you would expect. The summary is this: You may think increasing exploit costs is a simply good thing. But the side effect of relying on mitigations as opposed to software assurance is that it is getting extremely expensive to avoid being drowned in the noise. - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkrLUFgACgkQtehAhL0gherhJgCdH0rueH+25i6seTgikS7CE19e UdwAn1Tf31lo5c9qOs9zk8fdFukSnvNW =KSMa -----END PGP SIGNATURE----- From dan at geer.org Tue Oct 6 11:13:32 2009 From: dan at geer.org (dan at geer.org) Date: Tue, 06 Oct 2009 11:13:32 -0400 Subject: [Dailydave] Exploits matter. In-Reply-To: Your message of "Tue, 06 Oct 2009 10:12:40 EDT." <4ACB5058.7070503@immunityinc.com> Message-ID: <20091006151332.2BD2C3432D@absinthe.tinho.net> > > The summary is this: You may think increasing exploit costs > is a simply good thing. But the side effect of relying on > mitigations as opposed to software assurance is that it is > getting extremely expensive to avoid being drowned in the > noise. > The other side effect is that for exploitable vulnerabilities a rising fraction are privately held as the probability that you will give away something is inversely proportional to what it cost you to obtain it. --dan From dave at immunityinc.com Wed Oct 7 07:31:40 2009 From: dave at immunityinc.com (dave) Date: Wed, 07 Oct 2009 07:31:40 -0400 Subject: [Dailydave] Exploits matter. In-Reply-To: <20091006151332.2BD2C3432D@absinthe.tinho.net> References: <20091006151332.2BD2C3432D@absinthe.tinho.net> Message-ID: <4ACC7C1C.2090405@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This raises an interesting question. What is a "public" exploit? Buying CANVAS costs less than four thousand dollars and is (thankfully :>) a reasonably common thing for companies to have. If a working, 100% reliable exploit is in the hands of the ten thousand people who care, shouldn't that be considered "public"? It just seems weird to me that all the news articles on SMBv2 focus so much on whether or not you can download a working version of the exploit over the Internet, when all the people who could actually do anything with it already had it. - -dave dan at geer.org wrote: > > > > The summary is this: You may think increasing exploit costs > > is a simply good thing. But the side effect of relying on > > mitigations as opposed to software assurance is that it is > > getting extremely expensive to avoid being drowned in the > > noise. > > > > The other side effect is that for exploitable vulnerabilities > a rising fraction are privately held as the probability that > you will give away something is inversely proportional to what > it cost you to obtain it. > > > --dan > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkrMfBwACgkQtehAhL0gherNMwCfQXm3RGhLwk5ETO4DCgw/a257 CA4Aniz2UpfFjt08SWBNvw+UROkO2hup =EizD -----END PGP SIGNATURE----- From molney at sourcefire.com Wed Oct 7 09:24:23 2009 From: molney at sourcefire.com (Matt Olney) Date: Wed, 7 Oct 2009 09:24:23 -0400 Subject: [Dailydave] Exploits matter. In-Reply-To: <4ACC7C1C.2090405@immunityinc.com> References: <20091006151332.2BD2C3432D@absinthe.tinho.net> <4ACC7C1C.2090405@immunityinc.com> Message-ID: <77e259cc0910070624h44e3282fm4e11df822ba65dc7@mail.gmail.com> It isn't "weird", its "wrong". People hate to think about limited-distribution 0-day, like say December 2008 and Adobe JBIG, because the ramifications for computer security are so severe...something in the range of "You are screwed". They would rather spend hours working on Confickr because its a known threat and its something they can act against. It is also why vanilla CISSPs continue to get work, because ultimately in these cases your best defense is most likely an aggressive, oppressive (and enforced) infosec policy with accompanying network and security technology controls. And even then...most likely you are jacked. Or, as I often put it, defense sucks. It also speaks to a dramatic misunderestimation of the vulnerability development community that they can actually see (hello HD, Dave, Pusscat, Halvar, etc. etc. etc) and a complete ignorance of the threat they have no insight into (hello China, Iran, x-stan and Nebraska). Matt On Wed, Oct 7, 2009 at 7:31 AM, dave wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > This raises an interesting question. What is a "public" exploit? Buying > CANVAS costs less than four thousand dollars and is (thankfully :>) a > reasonably common thing for companies to have. If a working, 100% > reliable exploit is in the hands of the ten thousand people who care, > shouldn't that be considered "public"? > > It just seems weird to me that all the news articles on SMBv2 focus so > much on whether or not you can download a working version of the exploit > over the Internet, when all the people who could actually do anything > with it already had it. > > - -dave > > dan at geer.org wrote: >> ?> >> ?> The summary is this: You may think increasing exploit costs >> ?> is a simply good thing. But the side effect of relying on >> ?> mitigations as opposed to software assurance is that it is >> ?> getting extremely expensive to avoid being drowned in the >> ?> noise. >> ?> >> >> The other side effect is that for exploitable vulnerabilities >> a rising fraction are privately held as the probability that >> you will give away something is inversely proportional to what >> it cost you to obtain it. >> >> >> --dan >> >> _______________________________________________ >> Dailydave mailing list >> Dailydave at lists.immunitysec.com >> http://lists.immunitysec.com/mailman/listinfo/dailydave > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iEYEARECAAYFAkrMfBwACgkQtehAhL0gherNMwCfQXm3RGhLwk5ETO4DCgw/a257 > CA4Aniz2UpfFjt08SWBNvw+UROkO2hup > =EizD > -----END PGP SIGNATURE----- > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > From steve.shockley at shockley.net Wed Oct 7 09:56:14 2009 From: steve.shockley at shockley.net (Steve Shockley) Date: Wed, 07 Oct 2009 09:56:14 -0400 Subject: [Dailydave] Exploits matter. In-Reply-To: <4ACB5058.7070503@immunityinc.com> References: <4ACB5058.7070503@immunityinc.com> Message-ID: <4ACC9DFE.2090405@shockley.net> On 10/6/2009 10:12 AM, dave wrote: > But if you are like me, you are thinking "But it's still worth it". And > here's why: Without exploits, you have no way to know what matters. Or, > more realistically, what doesn't matter. I.E. in this case, 64 bit > computers are not going to be exploited with SMBv2 any time soon, of at > all. Since enterprises skipped Vista and use 64 bit for their Windows > 2008 servers, SMBv2 didn't hurt as badly as you would expect. Doesn't that just mean that *you* can't exploit it right now? Not trying to insult your haxxor skillz, but a few years ago you couldn't get a virus via email or Word, and null pointer dereference bugs could never be exploited. From tom at rooted.net Wed Oct 7 11:26:39 2009 From: tom at rooted.net (Tom Parker) Date: Wed, 7 Oct 2009 11:26:39 -0400 Subject: [Dailydave] Exploits matter. In-Reply-To: <4ACC7C1C.2090405@immunityinc.com> References: <20091006151332.2BD2C3432D@absinthe.tinho.net> <4ACC7C1C.2090405@immunityinc.com> Message-ID: IMO, when it comes to exploits.. as a rule of thumb; if it can be purchased in a non-exclusive manner, or found on the interwebs == public. I suppose you could argue that the second an exploit leaves your system, whether to give away, share with a peer for research purposes, or to sell - it becomes public; however there's obviously an element of subjectivity here. After all, one mans 0day that they just paid for when buying is the nexts 180+day. :> On Wed, Oct 7, 2009 at 7:31 AM, dave wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > This raises an interesting question. What is a "public" exploit? Buying > CANVAS costs less than four thousand dollars and is (thankfully :>) a > reasonably common thing for companies to have. If a working, 100% > reliable exploit is in the hands of the ten thousand people who care, > shouldn't that be considered "public"? > > It just seems weird to me that all the news articles on SMBv2 focus so > much on whether or not you can download a working version of the exploit > over the Internet, when all the people who could actually do anything > with it already had it. > > - -dave > > dan at geer.org wrote: > > > > > > The summary is this: You may think increasing exploit costs > > > is a simply good thing. But the side effect of relying on > > > mitigations as opposed to software assurance is that it is > > > getting extremely expensive to avoid being drowned in the > > > noise. > > > > > > > The other side effect is that for exploitable vulnerabilities > > a rising fraction are privately held as the probability that > > you will give away something is inversely proportional to what > > it cost you to obtain it. > > > > > > --dan > > > > _______________________________________________ > > Dailydave mailing list > > Dailydave at lists.immunitysec.com > > http://lists.immunitysec.com/mailman/listinfo/dailydave > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iEYEARECAAYFAkrMfBwACgkQtehAhL0gherNMwCfQXm3RGhLwk5ETO4DCgw/a257 > CA4Aniz2UpfFjt08SWBNvw+UROkO2hup > =EizD > -----END PGP SIGNATURE----- > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20091007/149feda0/attachment.htm From jericho at attrition.org Wed Oct 7 14:39:49 2009 From: jericho at attrition.org (security curmudgeon) Date: Wed, 7 Oct 2009 18:39:49 +0000 (UTC) Subject: [Dailydave] Exploits matter. In-Reply-To: <4ACC7C1C.2090405@immunityinc.com> References: <20091006151332.2BD2C3432D@absinthe.tinho.net> <4ACC7C1C.2090405@immunityinc.com> Message-ID: On Wed, 7 Oct 2009, dave wrote: : This raises an interesting question. What is a "public" exploit? Buying : CANVAS costs less than four thousand dollars and is (thankfully :>) a : reasonably common thing for companies to have. If a working, 100% : reliable exploit is in the hands of the ten thousand people who care, : shouldn't that be considered "public"? : : It just seems weird to me that all the news articles on SMBv2 focus so : much on whether or not you can download a working version of the exploit : over the Internet, when all the people who could actually do anything : with it already had it. Ten thousand or not, I cannot download the exploit from Immunity's web site, milw0rm or anywhere else, correct? To me, and to OSVDB who tracks that metric, that is flagged as 'rumored/private'. Can our industry really put a numeric line on public vs private in the scenario you describe? Do 9,999 CANVAS customers = private, but 10,000 CANAVAS customers = public? .b From lists at carnal0wnage.com Wed Oct 7 19:35:51 2009 From: lists at carnal0wnage.com (c0lists) Date: Wed, 7 Oct 2009 19:35:51 -0400 Subject: [Dailydave] Exploits matter. In-Reply-To: References: <20091006151332.2BD2C3432D@absinthe.tinho.net> <4ACC7C1C.2090405@immunityinc.com> Message-ID: <5c2b0f0b0910071635i56b62b1exddcbe78554556dc7@mail.gmail.com> On Wed, Oct 7, 2009 at 2:39 PM, security curmudgeon wrote: > > On Wed, 7 Oct 2009, dave wrote: > > : This raises an interesting question. What is a "public" exploit? Buying > : CANVAS costs less than four thousand dollars and is (thankfully :>) a > : reasonably common thing for companies to have. If a working, 100% > : reliable exploit is in the hands of the ten thousand people who care, > : shouldn't that be considered "public"? > : > : It just seems weird to me that all the news articles on SMBv2 focus so > : much on whether or not you can download a working version of the exploit > : over the Internet, when all the people who could actually do anything > : with it already had it. > > Ten thousand or not, I cannot download the exploit from Immunity's web > site, milw0rm or anywhere else, correct? To me, and to OSVDB who tracks > that metric, that is flagged as 'rumored/private'. > Then perhaps someone should update OSVDB to include "for pay" exploits/tools as a category just like bugtraq/bid does with comments. Because all those databases are incomplete it would be nice if "someone" would start putting that information in their db to say immunity has the exploit or core impact has the exploit. there is a big difference (to me) between rumored/private and for pay. -CG -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20091007/df40d6f2/attachment-0001.htm From jericho at attrition.org Wed Oct 7 19:49:57 2009 From: jericho at attrition.org (security curmudgeon) Date: Wed, 7 Oct 2009 23:49:57 +0000 (UTC) Subject: [Dailydave] Exploits matter. In-Reply-To: <5c2b0f0b0910071635i56b62b1exddcbe78554556dc7@mail.gmail.com> References: <20091006151332.2BD2C3432D@absinthe.tinho.net> <4ACC7C1C.2090405@immunityinc.com> <5c2b0f0b0910071635i56b62b1exddcbe78554556dc7@mail.gmail.com> Message-ID: On Wed, 7 Oct 2009, c0lists wrote: : > Ten thousand or not, I cannot download the exploit from Immunity's web : > site, milw0rm or anywhere else, correct? To me, and to OSVDB who tracks : > that metric, that is flagged as 'rumored/private'. : : Then perhaps someone should update OSVDB to include "for pay" : exploits/tools as a category just like bugtraq/bid does with comments. It's a good idea, but opens up additional issues from a VDB perspective. If the exploit is available for pay (e.g., via CANVAS), we flag it as such. Three months later it is published via milw0rm. Is there value in having it flagged 'for pay' and 'public'? Or do we need to then consider adding a better date history? We currently track 7 dates, one of them being 'exploit published' (public). An 8th date field for 'exploit developed' perhaps? : Because all those databases are incomplete it would be nice if "someone" : would start putting that information in their db to say immunity has the : exploit or core impact has the exploit. It would also be nice if these companies would provide a little better public mechanism for disclosing that information, that can be easily referenced by a VDB. Dave posted to the list about the recent vulnerability, but there are hundreds more Immunity developed with no easily referenced date or details. Because vulnerability information is valuable, we also run into the problem of not knowing if two companies have the same vulnerability figured out, if a vendor's recent announcement about fixing an 'overflow' is the same one as a researcher's, etc. This is becoming a big headache for VDBs; the VulnDisco work by Evgeny is a good example. : there is a big difference (to me) between rumored/private and for pay. Yes. For a simple classification system, rumored/private was a better fit given: - Exploit available (public) - Exploit unavailable (none exists) - Exploit rumored / private (exists, not public) - Exploit unknown This is very simple, but the best we wanted to do originally. Times have obviously changed, and adding a little better abstraction is in order. 'Rumored' by itself has no value, especially long term. The question is now how best to expand it without getting too granular and losing focus. We'd love any input on this. From lists at carnal0wnage.com Wed Oct 7 20:17:45 2009 From: lists at carnal0wnage.com (c0lists) Date: Wed, 7 Oct 2009 20:17:45 -0400 Subject: [Dailydave] Exploits matter. In-Reply-To: References: <20091006151332.2BD2C3432D@absinthe.tinho.net> <4ACC7C1C.2090405@immunityinc.com> <5c2b0f0b0910071635i56b62b1exddcbe78554556dc7@mail.gmail.com> Message-ID: <5c2b0f0b0910071717y418a8374y9ed66ec1e92e894f@mail.gmail.com> On Wed, Oct 7, 2009 at 7:49 PM, security curmudgeon wrote: > > > On Wed, 7 Oct 2009, c0lists wrote: > > : Because all those databases are incomplete it would be nice if "someone" > : would start putting that information in their db to say immunity has the > : exploit or core impact has the exploit. > > It would also be nice if these companies would provide a little better > public mechanism for disclosing that information, that can be easily > referenced by a VDB. Dave posted to the list about the recent > vulnerability, but there are hundreds more Immunity developed with no > easily referenced date or details. > > Because vulnerability information is valuable, we also run into the > problem of not knowing if two companies have the same vulnerability > figured out, if a vendor's recent announcement about fixing an 'overflow' > is the same one as a researcher's, etc. This is becoming a big headache > for VDBs; the VulnDisco work by Evgeny is a good example. > I agree. It would seem to be in their best interest to allows maintainers of exploit databases to have access to the exploit metadata even if it wasnt in real time (perhaps quarterly) and would be very little overhead. Most of the updates go into their monthly "download our new version" or "updated moduels" emails anyway. That certainly doesnt address all the issues you brought up but would be a step in the right direction. Maybe Immunity can start :-) -CG -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20091007/aa5a1875/attachment.htm From jericho at attrition.org Thu Oct 8 04:05:53 2009 From: jericho at attrition.org (security curmudgeon) Date: Thu, 8 Oct 2009 08:05:53 +0000 (UTC) Subject: [Dailydave] Exploits matter. In-Reply-To: <4ACD9390.1000408@yourcreativesolutions.nl> References: <20091006151332.2BD2C3432D@absinthe.tinho.net> <4ACC7C1C.2090405@immunityinc.com> <4ACD9390.1000408@yourcreativesolutions.nl> Message-ID: Hi Wouter, : > Ten thousand or not, I cannot download the exploit from Immunity's web site, : > milw0rm or anywhere else, correct? To me, and to OSVDB who tracks that : > metric, that is flagged as 'rumored/private'. : > : > Can our industry really put a numeric line on public vs private in the : > scenario you describe? Do 9,999 CANVAS customers = private, but 10,000 : > CANAVAS customers = public? : In the more formalized evaluation worlds (Common Criteria, EMVco, etc), the : concept "public/private" is really just one input for the calculation of the : cost to the attacker. In those terms, the costs in dollars over time would be : something like this: : * Prior to discovery that that part of the SMBv2 implementation had a : potential place to attack: fuzzing+analysis, what about 6 person months (this : is really a wild guess, anyone have a good number on this?), so say ~$60.000. : * From discovery to CANVAS-integrated attack: 3 person months, so say ~$30.000 : * Now in CANVAS (and you'll get way more goodies with it): ~$4.000 : * When it will be on milw0rm etc: time to make it work properly, ~$200? : : So the "public/private" discussion in my view is a discussion between a $4.000 : and a $200 attack, both of which I cannot understand that youwould call be an : investment that is too steep for a real attacker. : : Although I can understand from OSVDB point of view that they cannot confirm : the status, it is disturbing that apparently people are using the uncertainty : of the measurement (of the OSVDB in this case) to doubt whether it is in the : $30.000 or $200 range. Uh, either I do not fully understand your point, or I do not fully understand where you misunderstood how the economy works, at least in the U.S. The difference betwene $US 30 and $US 200 is big. The difference between $US 30,000 and $200 is even bigger. I mention that because I believe your . in the 30.000 value really means 30,000, which is a huge difference to us Americans. Regardless of your use of . vs , anyone versed in math or economics could lecture on percentages of 30 and 200, or 200 and 30000. As applies to OSVDB, if I am doubting our ability to intellectually track "public vs private", then the debate over the dollar value should not be very relevant, especially in a historic context. : I'd expect that the vulnerability database crowd would have a "X claims : to have the exploit working, here is X's history of those claims so X : seems to be truthful in his claims"-construction to cover this. If so, : if it is easy to provide such info to the vulnerability database it Oh sweet jesus, no you didn't! What you propose is based on what the VDB world calls "researcher confidence". Meaning, the VDBs actually track a history of disclosure for a given individual, track the vulnerabilities they publish, the severity of those vulns, the products they were found in, the number of third-party disputes, the number of vendor-disputes, and several other metrics, to calculate a 'resarcher confidence' score. OSVDB actually began to track classification entries that help calculate such scores with "third-party verified", "third-party disputed", "vendor verified" and "vendor disputed". There was a slight method to our madness. This has been in demand for more than five years, not only by OSVDB, but by specific people at CVE and other VDBs as well. For mostly political reasons, OSVDB has been slowly working toward the ability to track this metric while the others watched with anticipation. In the last few years, we have also begun to discuss and implement a framework for tracking *vendor confidence*. It isn't only researchers that are flaky and ill-equipped to handle vulnerability disclosure. =) While beating my chest in primitive style, and hopped up on too many glasses of scotch, i'll go ahead and say that only OSVDB has really begun to address and implement such scoring mechanisms. Disclaimer: really smart guys from other VDBs have given input in our discussions, but cannot implement such a system on their own. Disclaimer #2: Even after all the discussion, we're left with a classic problem of deciding a system that is a perfect balance between 'over simplified' (and inaccurate) and 'overly complex' (and convoluted). Long story short, we're working on a better way to classify both resarcher and vendor confidence scores. Even a small hint of that, has caused some notable panic in the *vendor* world, not the researcher world. : would seem good marketing for vendors of tools like CANVAS to fill it : with "we can already do this". That way, someone researching the : potential vulnerabilities in his shiny new Windows server will find the : remark that SMBv2 could be a serious problem, and see the hint that : CANVAS could be used to check. Or is this too simple in the market : reality? I'll go ahead and throw the gauntlet down to Dave and Immunity. OSVDB has discussed ways to better implement some of these metrics, specifically an overhaul to our classification system regarding exploit availability, as well as "vulnerability framework" vendors, free and commercial, to share with us a better understanding of what they have in their arsenal without giving away details that are a detriment to their commercial advantage. (that last sentences makes me sick on one level, fascinated on another) Would *any* vendor out there, developing exploits, give OSVDB a matching of CVE or OSVDB ID, along with their commercial capability to exploit the vulnerability? More specifically, not just a yes/no, but a date they had developed such an exploit? If the vendor was considered reliable (yes, we've been tracking to some degree in sekrit), we'd make such information a part of our database. OSVDB would in turn break from tradition, and offer a link back to that vendor, under the 'Tools & Filters' section of our display. While it may seem rather unassuming, it would be the first time we did not link to a public/free resource, and fully demonstrate the capability and full arsenal your company had to offer. Hell, even giving us a 75% matching (say, delayed by 30 days?) would be a fascinating metric to track. So far, the only companies that have shown us a *hint* of this information are iDefense, Tipping Point and some random guy named Evgeny Legerov. Bottom line, we'd love to track more information, develop more meaningful metrics and produce more relevant analysis. However, we're limited by the reliable dataset we have available. : BTW, more philosophical: it does show the enormous cost decrease to the : attacker over time (~2-3 months calender time?), i.e. 0days custom : developed are orders more expensive, and the hidden cost of : "weaponizing" it is what tools like CANVAS solve for quite a cheap : price. It does, you are right. But one thing keeps sticking in my mind. While companies like Immunity spend 30 days with X researchers to write a vulnerability, companies like Tenable, SAINT and Qualys are taking 2 - 5 days to reverse and figure out a working vulnerability check. Not an exploit, but a way of determining exploitability, both locally and remotely. Those vendors have to be putting extra pressure on shops like Immunity or others, as they severely limit the window between 2-5 and 30 days, as many high value targets patch their systems, before a working / weaponized exploit is developed. Yet another variable in determining the value or timeframes of everything discussed. From ig at hexblog.com Thu Oct 8 04:47:19 2009 From: ig at hexblog.com (Ilfak Guilfanov) Date: Thu, 08 Oct 2009 10:47:19 +0200 Subject: [Dailydave] Exploits matter. In-Reply-To: <4ACC9DFE.2090405@shockley.net> References: <4ACB5058.7070503@immunityinc.com> <4ACC9DFE.2090405@shockley.net> Message-ID: <4ACDA717.6040909@hexblog.com> Sorry for my ignorance, are NULL pointer dereference bugs exploitable today? Steve Shockley said the following on 7/10/2009 15:56: > On 10/6/2009 10:12 AM, dave wrote: >> But if you are like me, you are thinking "But it's still worth it". And >> here's why: Without exploits, you have no way to know what matters. Or, >> more realistically, what doesn't matter. I.E. in this case, 64 bit >> computers are not going to be exploited with SMBv2 any time soon, of at >> all. Since enterprises skipped Vista and use 64 bit for their Windows >> 2008 servers, SMBv2 didn't hurt as badly as you would expect. > > Doesn't that just mean that *you* can't exploit it right now? Not > trying to insult your haxxor skillz, but a few years ago you couldn't > get a virus via email or Word, and null pointer dereference bugs could > never be exploited. > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave -- Best regards, Ilfak mailto:ig at hexblog.com From mjw at cyberwart.com Thu Oct 8 09:58:26 2009 From: mjw at cyberwart.com (Matthew Wollenweber) Date: Thu, 8 Oct 2009 09:58:26 -0400 Subject: [Dailydave] Exploits matter. In-Reply-To: <5c2b0f0b0910071717y418a8374y9ed66ec1e92e894f@mail.gmail.com> References: <20091006151332.2BD2C3432D@absinthe.tinho.net> <4ACC7C1C.2090405@immunityinc.com> <5c2b0f0b0910071635i56b62b1exddcbe78554556dc7@mail.gmail.com> <5c2b0f0b0910071717y418a8374y9ed66ec1e92e894f@mail.gmail.com> Message-ID: <5fb633320910080658q6c0de3a8h57fa12713721b829@mail.gmail.com> It might be a little more informative to add an extra field to various databases. I say maybe, as unless the databases actually test the exploits accuracy would be questionable. But I think the marginal difference between the terms "private/rumored" and "private/for sale" doesn't examine the underlying problem -- which is what Matt Olney and I believe Dave were getting at. The practical distinction between public and private doesn't mean much. For $1000 you can have the exploit from Immunity -- or you can likely get it for free if you know someone. That's not a particularly high bar, but most organizations treat private exploits (and by that I mean anything not on milw0rm, metasploit, or bugtraq) as an unfathomable problem. So they obviously ignore it. Now the above is precisely the problem (IMO). It's pretty easy to buy "private" exploits. It's pretty easy to write simple stack buffer overflows that you'll find in vast amounts of in-house software. It's pretty easy to use a packer to get past most or all AV. All of the above will generally be near completely immune to most defenses. These are insurmountable problems in the eyes of most businesses. When considering defending against these threats, you might have better luck convincing them to train school kids to defend against the military. This is why they focus on whether one can easily download the exploit or not. If so, then they have a problem that's in their process to tackle. If not, it's too hard and they accept the risk. They prefer the latter. When you consider that it's "pretty easy" to do several things that are insurmountable problems to most businesses then you really begin to see the problem. Defense security people like to gripe about people that release exploits. It's a natural response given that their lives are made more difficult. Ultimately, they're going to have to tackle the above type problems, and (IMO) full-disclosure pushes them one step closer to admitting the current security balance isn't acceptable. Since many exploits are more difficult these days, there's going to be more private/for-sale exploits and hopefully they'll begin to tackle these problems. Until then, I expect to hear much more whining. /rant. On Wed, Oct 7, 2009 at 8:17 PM, c0lists wrote: > > > On Wed, Oct 7, 2009 at 7:49 PM, security curmudgeon > wrote: >> >> >> On Wed, 7 Oct 2009, c0lists wrote: >> >> : Because all those databases are incomplete it would be nice if "someone" >> : would start putting that information in their db to say immunity has the >> : exploit or core impact has the exploit. >> >> It would also be nice if these companies would provide a little better >> public mechanism for disclosing that information, that can be easily >> referenced by a VDB. Dave posted to the list about the recent >> vulnerability, but there are hundreds more Immunity developed with no >> easily referenced date or details. >> >> Because vulnerability information is valuable, we also run into the >> problem of not knowing if two companies have the same vulnerability >> figured out, if a vendor's recent announcement about fixing an 'overflow' >> is the same one as a researcher's, etc. This is becoming a big headache >> for VDBs; the VulnDisco work by Evgeny is a good example. > > I agree. It would seem to be in their best interest to allows maintainers of > exploit databases to have access to the exploit metadata even if it wasnt in > real time (perhaps quarterly) and would be very little overhead. Most of the > updates go into their monthly "download our new version" or "updated > moduels" emails anyway. > > That certainly doesnt address all the issues you brought up but would be a > step in the right direction. Maybe Immunity can start :-) > > -CG > > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > > From tom at rooted.net Thu Oct 8 10:01:14 2009 From: tom at rooted.net (Tom Parker) Date: Thu, 8 Oct 2009 10:01:14 -0400 Subject: [Dailydave] Exploits matter. In-Reply-To: References: <20091006151332.2BD2C3432D@absinthe.tinho.net> <4ACC7C1C.2090405@immunityinc.com> Message-ID: On Wed, Oct 7, 2009 at 2:39 PM, security curmudgeon wrote: > Ten thousand or not, I cannot download the exploit from Immunity's web > site, milw0rm or anywhere else, correct? To me, and to OSVDB who tracks > that metric, that is flagged as 'rumored/private'. > Can our industry really put a numeric line on public vs private in the > scenario you describe? Do 9,999 CANVAS customers = private, but 10,000 > CANAVAS customers = public? > While I understand the challenge of verifying the existence and nature of commercial exploitation tools, down playing exploits by databases like OSVDB is damaging to the industry and is creating a false sense of security amongst organizations - especially those who charge their security programs to vanilla CISSP's. Case in point - large company runs an automated scanner over their network on a monthly basis, which regularly finds flaws. They prioritize remediation of findings based on CVSS scores, which have been calculated in part through utilizing data from OSVDB. Days, months, weeks later the organization is attacked/audited by a group who paid/stole/borrowed a copy of Canvas/Core/et al. Organization gets owned. The past two VzB data breach reports have demonstrated a trend, that a large number of compromises (around 70% if memory serves), resulted from exploitation of vulnerabilities that at time of compromise had been patched by the vendor for a year or more. I'm not sure how you would go about obtaining this kind of data (or indeed how VzB gets their data), but it would be an interesting metric to see how many of those known/vendor-patched issues had been neglected/de-prioritized due to misconceptions about their level of exploitability. It would indeed be a good thing if Immunity et al would publish some kind of unified database of their proprietary exploits, mapped to CVE-ID etc, but I'm not sure if it's their responsibility to do so. IMO, the scanning vendors, Qualys, Rapid7, nCircle etc are missing a trick if they aren't buying themselves a copy of CANVAS and ensuring that when their scanner finds a vulnerability supported by it [CANVAS], they are providing users a CVSS score based on the fact that they have independently verified the existence of robust exploit code for the respective vuln. -Tom > .b > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20091008/034080ac/attachment-0001.htm From alex at sotirov.net Thu Oct 8 12:11:42 2009 From: alex at sotirov.net (Alexander Sotirov) Date: Thu, 8 Oct 2009 12:11:42 -0400 Subject: [Dailydave] Exploits matter. In-Reply-To: <4ACDA717.6040909@hexblog.com> References: <4ACB5058.7070503@immunityinc.com> <4ACC9DFE.2090405@shockley.net> <4ACDA717.6040909@hexblog.com> Message-ID: <20091008161142.GA3139@MacBook-2.local> On Thu, Oct 08, 2009 at 10:47:19AM +0200, Ilfak Guilfanov wrote: > Sorry for my ignorance, are NULL pointer dereference bugs exploitable today? Hi Ilfak, NULL pointer dereferences in userspace programs are generally not exploitable, but in some rare cases they might be. For example, Mark Dowd published a Flash exploit where a NULL pointer was used as the base of an array that was accessed with an arbitrary array index. This turned the NULL pointer dereference into an arbitrary memory write operation. Here's his detailed writeup about the exploit: http://documents.iss.net/whitepapers/IBM_X-Force_WP_final.pdf This exploitation technique (and other interesting ones) were also described in a really under-appreciated presentation by Ga?l Delalleau at CanSecWest 2005: http://cansecwest.com/core05/memory_vulns_delalleau.pdf In the Linux kernel, NULL pointer dereferences are exploitable in many cases, because the user can mmap memory at address 0 through a variety of techniques and take control of the data structure the kernel is dereferencing. Brad Spender has released multiple Linux local privilege escalation exploits to prove this point. See this blog post for more info: http://blog.cr0.org/2009/06/bypassing-linux-null-pointer.html Take care, Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20091008/7371e7c2/attachment.pgp From apconole at yahoo.com Thu Oct 8 13:19:12 2009 From: apconole at yahoo.com (Aaron) Date: Thu, 8 Oct 2009 10:19:12 -0700 (PDT) Subject: [Dailydave] Exploits matter. In-Reply-To: <4ACDA717.6040909@hexblog.com> References: <4ACB5058.7070503@immunityinc.com> <4ACC9DFE.2090405@shockley.net> <4ACDA717.6040909@hexblog.com> Message-ID: <771076.56612.qm@web65403.mail.ac4.yahoo.com> Under linux, it's as easy as setting your "personality" to SYSVR4, mmap'ing the 0th address, and filling it with your code. That's for local exploit anyway. I'm not sure about remotely exploiting a NULL dereference, or about non-linux systems (read: it may be possible, but I just don't know for sure one way or the other). ________________________________ From: Ilfak Guilfanov To: Steve Shockley Cc: dailydave at lists.immunitysec.com Sent: Thu, October 8, 2009 4:47:19 AM Subject: Re: [Dailydave] Exploits matter. Sorry for my ignorance, are NULL pointer dereference bugs exploitable today? Steve Shockley said the following on 7/10/2009 15:56: > On 10/6/2009 10:12 AM, dave wrote: >> But if you are like me, you are thinking "But it's still worth it". And >> here's why: Without exploits, you have no way to know what matters. Or, >> more realistically, what doesn't matter. I.E. in this case, 64 bit >> computers are not going to be exploited with SMBv2 any time soon, of at >> all. Since enterprises skipped Vista and use 64 bit for their Windows >> 2008 servers, SMBv2 didn't hurt as badly as you would expect. > > Doesn't that just mean that *you* can't exploit it right now? Not > trying to insult your haxxor skillz, but a few years ago you couldn't > get a virus via email or Word, and null pointer dereference bugs could > never be exploited. > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave -- Best regards, Ilfak mailto:ig at hexblog.com _______________________________________________ Dailydave mailing list Dailydave at lists.immunitysec.com http://lists.immunitysec.com/mailman/listinfo/dailydave -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20091008/ab7dc86a/attachment.htm From alexm at immunityinc.com Thu Oct 8 15:11:43 2009 From: alexm at immunityinc.com (alexm) Date: Thu, 08 Oct 2009 15:11:43 -0400 Subject: [Dailydave] Exploits matter. In-Reply-To: References: <20091006151332.2BD2C3432D@absinthe.tinho.net> <4ACC7C1C.2090405@immunityinc.com> Message-ID: <4ACE396F.50301@immunityinc.com> Tom Parker wrote: >> It would indeed be a good thing if Immunity et al would publish some kind of >> unified database of their proprietary exploits, mapped to CVE-ID etc, but >> I'm not sure if it's their responsibility to do so. IMO, the scanning >> vendors, Qualys, Rapid7, nCircle etc are missing a trick if they aren't >> buying themselves a copy of CANVAS and ensuring that when their scanner >> finds a vulnerability supported by it [CANVAS], they are providing users a >> CVSS score based on the fact that they have independently verified the >> existence of robust exploit code for the respective vuln >> Most of our exploits are mapped to their respective CVE numbers, many months ago we made an internal push to get everything much more uniform within the documentation dicts of exploit modules. We include CVE Number, CVE URL and since we do a lot of Microsoft bugs the MS security number as appropriate. With some of our 3rd party vendors who deal in 0day obviously CVE numbers are not available and sometimes exploits will be developed against bugs that are silently patched, so it's not a perfect system. We had a lot of customer requests for being able to import results from some vulnerability scanning tools. Looking at the formats for those files we realized that all the major scanning tools had an option to report vulnerabilities as their CVE number. So the way this specific part of the code works is that once hosts and CVEs are parsed out of the report, those CVE numbers which have corresponding CANVAS modules are kept and attributed to the host while those that do not have modules are dumped. One of the primary usage cases we see for CANVAS works like this: 1) Use vulnerability scanning product X over network segment 2) X returns a list of potential vulnerabilities against the hosts on that segment 3) Start CANVAS, import list, run the appropriate modules against the imported hosts So while it's not our responsibility as such to maintain this reference between exploit modules and CVEs I think it's in our best interests to do so and we've got a pretty strong case from our customers to make it happen. I'm sure the other products/projects in this space do similar things. Cheers, -AlexM From vhinderer at lexsi.com Thu Oct 8 16:30:58 2009 From: vhinderer at lexsi.com (vincent hinderer) Date: Thu, 08 Oct 2009 22:30:58 +0200 Subject: [Dailydave] Exploits matter. In-Reply-To: Message-ID: >> > > While I understand the challenge of verifying the existence and nature of > commercial exploitation tools, down playing exploits by databases like OSVDB > is damaging to the industry and is creating a false sense of security amongst > organizations - especially those who charge their security programs to vanilla > CISSP's. Case in point - large company runs an automated scanner over their > network on a monthly basis, which regularly finds flaws. They prioritize > remediation of findings based on CVSS scores, which have been calculated in > part through utilizing data from OSVDB. Days, months, weeks later the > organization is attacked/audited by a group who paid/stole/borrowed a copy of > Canvas/Core/et al. Organization gets owned. > > I agree. Working these days on patching a 2003 (!) flaw... > > The past two VzB data breach reports have demonstrated a trend, that a large > number of compromises (around 70% if memory serves), resulted from > exploitation of vulnerabilities that at time of compromise had been patched by > the vendor for a year or more. I'm not sure how you would go about obtaining > this kind of data (or indeed how VzB gets their data), but it would be an > interesting metric to see how many of those known/vendor-patched issues had > been neglected/de-prioritized due to misconceptions about their level of > exploitability. > In Verizon report : patch availability at time of attack -between 0,5 to 1 year = 1 -for more than 1 year = 5 (83%) Total of attacks = 6 A relatively small set to draw conclusions though... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20091008/75dd51fe/attachment-0001.htm From jericho at attrition.org Thu Oct 8 17:53:05 2009 From: jericho at attrition.org (security curmudgeon) Date: Thu, 8 Oct 2009 21:53:05 +0000 (UTC) Subject: [Dailydave] Exploits matter. In-Reply-To: <4ACDBF7A.7080400@yourcreativesolutions.nl> References: <20091006151332.2BD2C3432D@absinthe.tinho.net> <4ACC7C1C.2090405@immunityinc.com> <4ACD9390.1000408@yourcreativesolutions.nl> <4ACDBF7A.7080400@yourcreativesolutions.nl> Message-ID: : > The difference betwene $US 30 and $US 200 is big. The difference between $US : > 30,000 and $200 is even bigger. I mention that because I believe your . in : > the 30.000 value really means 30,000, which is a huge difference to us : > Americans. Regardless of your use of . vs , anyone versed in math or : > economics could lecture on percentages of 30 and 200, or 200 and 30000. : There is no need to flame bate, I only inserted the dots (yes, European style, I apologize, it was not my intention to be flame bait. I just wanted to make the distinction that trying to track value, while very intersting, is definitely outside the scope of what a VDB can realistically track. : > As applies to OSVDB, if I am doubting our ability to intellectually track : > "public vs private", then the debate over the dollar value should not be : > very relevant, especially in a historic context. : So if I understand you correctly, for you "public versus private" is : more useful in the decision whether to worry about some rumored attack : then the difficulty for a given attacker? Or to ask it differently, I : would worry based on the cost to one attacker (i.e. under the assumption : that there is always one), not on the amount of attackers, whereas you : seem to worry about the amount of attackers (based on their access to : the attack)? OSVDB wants to track public vs private (and likely a more granular metric), unrelated to someone using us as a source on 'should we worry?'. I certainly hope no one uses us as a definitive source on the status of an exploit other than a link we may provide to it. We also have no intention of tracking the amount of attackers, be it companies like Immunity or Core or trying to determine how many bad guys may be out there that developed it. : > In the last few years, we have also begun to discuss and implement a : > framework for tracking *vendor confidence*. It isn't only researchers that : > are flaky and ill-equipped to handle vulnerability disclosure. =) : Interesting, I did not know it was already so far in software : vulnerability domain. So in essence there is already for a long time a : mechanism to describe "claimed to be privately available" in the : vulnerability databases (and apparently from your heated reaction, this : was hard won. Kudos!). That means Dave's original question still holds: It was, and its still in its infancy. Despite that, every VDB uses their own form of resarcher confidence. Unfortunately, most (including OSVDB) can only do it based on personal history of working on a VDB. Our goal is to actually define that confidence level, show our 'math' and publish it. The knowledge I have of vulnerability disclosure as pertains to the researchers and their reliability should not die with me. Anyone should be able to look at that history should they need it (e.g., hiring purposes, risk assessment). : why is it then so important that it is public (i.e. for free for all) or : commercially available for $4000 from a reputable vendor to anyone that : can pay that amount? I mean a free public exploit is more likely to I don't think it is that important, it's an interesting metric to track. We run into this often; we think "it would be neat to track X" then debate it to death, determining if it is valuable to users, relevant to the database or will end up having more issues and uncertainty than value. : I can imagine that that is because of the different views. : The researchers see their confidence scores as selling point, a higher score : means more importance hence more market value (in money, prestige, Kudos, : whatever). The good ones also want something to clearly distinguish them from : the wannabes with good marketing. True, but it can bite someone in the ass too. If they publish 100 vulnerabilities and 20% end up being incorrect, that could later haunt them if they try to work for a company doing vulnerability research. : > overhaul to our classification system regarding exploit availability, as : > well as "vulnerability framework" vendors, free and commercial, to share : > with us a better understanding of what they have in their arsenal without : > giving away details that are a detriment to their commercial advantage. : Interesting. So the market isn't picking up on it but it is not clear yet why. : Your proposal later on looks like a serious step towards it. I think it is obvious personally. If I say there is a remote overflow in product X, that is all it really takes for a skilled researcher to start dissecting the software and figure it out. There has to be a serious balance in what you advertise you have as far as 0-day, or you run the risk of giving away too much and devaluing your product. Immunity advertises the exploits they have for published vulnerabilities because it gives nothing away. If they say "we have a remote for apache" that is vague. If they say "we have a remote for apache related to header handling", that likely significantly reduces the time required for a third party to find the issue. : Good point. I think this (and my confusion about why it matters) comes down to : different levels of assurance one is seeking. I recently (at the CC conference : 2 weeks ago) sat in a panel next to Oracle and Microsoft as the "big software : companies", informally representing the smartcard community. I was struck at : the different realities the two domains have and this seems to apply here : also. : : In the general software domain, the products are so huge that there is : inevitably huge amounts of bugs in there and have essentially next to no : defense in depth so in many cases it is exploitable also. So there your : timeline point is valid, i.e. the time between possibility to patch (with a : need to patch, maybe here is the public/private discussion?) and the : weaponized exploits is the window of opportunity. So anything that reduces : this (silently patching by the vendor, quickly patching, pressuring to : avoid/delay disclosure, etc) is useful. Your proposal would create very : interesting measurements on timing especially. Absolutely. Unfortunately, due to time and lack of information, it could likely only be done with the big vulnerabilities; the Microsoft, Oracle and Cisco remotes. The 'lesser' vulnerabilities, even if being widely exploited (e.g., SQLi), don't come with enough information to do that analysis I bet. : Interesting discussion, thank you! Very =) From jericho at attrition.org Thu Oct 8 18:07:34 2009 From: jericho at attrition.org (security curmudgeon) Date: Thu, 8 Oct 2009 22:07:34 +0000 (UTC) Subject: [Dailydave] Exploits matter. In-Reply-To: References: <20091006151332.2BD2C3432D@absinthe.tinho.net> <4ACC7C1C.2090405@immunityinc.com> Message-ID: On Thu, 8 Oct 2009, Tom Parker wrote: : > Ten thousand or not, I cannot download the exploit from Immunity's web : > site, milw0rm or anywhere else, correct? To me, and to OSVDB who tracks : > that metric, that is flagged as 'rumored/private'. : : > Can our industry really put a numeric line on public vs private in the : > scenario you describe? Do 9,999 CANVAS customers = private, but 10,000 : > CANAVAS customers = public? : : While I understand the challenge of verifying the existence and nature : of commercial exploitation tools, down playing exploits by databases : like OSVDB is damaging to the industry and is creating a false sense of How exactly does OSVDB 'downplay' exploits using the current classification system? We're the only VDB to even say "an exploit likely exists, even though not public" which should be the opposite of downplaying. If you have a good answer to that, how can we improve the classification system to more accurately track such metrics, without causing a problem? : security amongst organizations - especially those who charge their : security programs to vanilla CISSP's. Case in point - large company runs : an automated scanner over their network on a monthly basis, which : regularly finds flaws. They prioritize remediation of findings based on : CVSS scores, which have been calculated in part through utilizing data : from OSVDB. Days, months, weeks later the organization is : attacked/audited by a group who paid/stole/borrowed a copy of : Canvas/Core/et al. Organization gets owned. First, we display CVSS scores as calculated by NVD if there is a CVE assignment. We will calculate our own scores if we a) disagree or b) have an entry w/o a CVE. Either way, I don't quite follow the logic above, as applies to how OSVDB (or any VDB) is doing wrong or contributing to the problem. : The past two VzB data breach reports have demonstrated a trend, that a : large number of compromises (around 70% if memory serves), resulted from : exploitation of vulnerabilities that at time of compromise had been : patched by the vendor for a year or more. I'm not sure how you would go : about obtaining this kind of data (or indeed how VzB gets their data), They get their data from their own clients, based on forensic examination post-compromise. : but it would be an interesting metric to see how many of those : known/vendor-patched issues had been neglected/de-prioritized due to : misconceptions about their level of exploitability. That would be a really neat addition to the report next year. : It would indeed be a good thing if Immunity et al would publish some : kind of unified database of their proprietary exploits, mapped to CVE-ID : etc, but I'm not sure if it's their responsibility to do so. IMO, the I'd love for them to use CVE or another VDB to do just that. They have absolutely zero responsibility to do it, and it has a bigger chance of hurting them than helping them (see my previous post about disclosing your 0-day). : scanning vendors, Qualys, Rapid7, nCircle etc are missing a trick if : they aren't buying themselves a copy of CANVAS and ensuring that when : their scanner finds a vulnerability supported by it [CANVAS], they are : providing users a CVSS score based on the fact that they have : independently verified the existence of robust exploit code for the : respective vuln. I believe many of these products have licenses that prevent reverse engineering. If a company like the ones you mention above were to obtain a copy, they would be violating the licensing and possibly the law. If a scanner had a consistent pattern of adding checks that mirrored an exploit framework, it would be pretty easy for them to be called out. From mr.monkey at gmail.com Thu Oct 8 20:51:13 2009 From: mr.monkey at gmail.com (Fuzzy Hoodie-Monster) Date: Thu, 8 Oct 2009 17:51:13 -0700 Subject: [Dailydave] Exploits matter. In-Reply-To: <77e259cc0910070624h44e3282fm4e11df822ba65dc7@mail.gmail.com> References: <20091006151332.2BD2C3432D@absinthe.tinho.net> <4ACC7C1C.2090405@immunityinc.com> <77e259cc0910070624h44e3282fm4e11df822ba65dc7@mail.gmail.com> Message-ID: <7abc832d0910081751h7f2e36fep8f9faf1b83aa6483@mail.gmail.com> On Wed, Oct 7, 2009 at 6:24 AM, Matt Olney wrote: > Or, as I often put it, defense sucks. Except that Dave started this thread by saying how much harder it was to develop this exploit than in the old days. From jesse_gough at symantec.com Thu Oct 8 20:57:00 2009 From: jesse_gough at symantec.com (Jesse Gough) Date: Thu, 8 Oct 2009 17:57:00 -0700 Subject: [Dailydave] Exploits matter. In-Reply-To: <20091008161142.GA3139@MacBook-2.local> References: <4ACB5058.7070503@immunityinc.com> <4ACC9DFE.2090405@shockley.net> <4ACDA717.6040909@hexblog.com> <20091008161142.GA3139@MacBook-2.local> Message-ID: <20091009005700.GA1554@symantec.com> On Thu, 08 Oct 2009, Alexander Sotirov wrote: > On Thu, Oct 08, 2009 at 10:47:19AM +0200, Ilfak Guilfanov wrote: > > Sorry for my ignorance, are NULL pointer dereference bugs exploitable today? > > Hi Ilfak, > > NULL pointer dereferences in userspace programs are generally not exploitable, > but in some rare cases they might be. For example, Mark Dowd published a Flash > exploit where a NULL pointer was used as the base of an array that was accessed > with an arbitrary array index. This turned the NULL pointer dereference into an > arbitrary memory write operation. Here's his detailed writeup about the exploit: > http://documents.iss.net/whitepapers/IBM_X-Force_WP_final.pdf > > This exploitation technique (and other interesting ones) were also described > in a really under-appreciated presentation by Ga?l Delalleau at CanSecWest 2005: > http://cansecwest.com/core05/memory_vulns_delalleau.pdf > > In the Linux kernel, NULL pointer dereferences are exploitable in many cases, > because the user can mmap memory at address 0 through a variety of techniques > and take control of the data structure the kernel is dereferencing. Brad > Spender has released multiple Linux local privilege escalation exploits > to prove this point. See this blog post for more info: > http://blog.cr0.org/2009/06/bypassing-linux-null-pointer.html > > Take care, > Alex There is also Barnaby Jack's paper on exploiting NULL derefs on ARM and XScale. Conveniently, address 0 holds the exception vector table, which turns out to be a pretty convenient place to write to :) http://www.juniper.net/solutions/literature/white_papers/Vector-Rewrite-Attack.pdf Another example against Internet Explorer from a few years ago: http://www.uninformed.org/?v=4&a=5&t=txt There is a bit of a semantic issue. First of all, consider that memory address 0x00000000 is technically just as valid of a memory address as 0xbfffffff. Its not as if there is a missing transistor on your DRAM chips at the first addressable position. With virtual memory abstracting you anyway, there is even less reason to accept this as truth and equating 0x00000000 with NULL. If your operating environment imposes this restriction on you, it is purely artificial. Furthermore, there is no reason to accept that such a restriction could not be subverted or removed. So I suppose technically speaking, no, NULL dereferences are not exploitable. However, don't assume address 0 means NULL, because an address 0 dereference could be exploitable. But, that is a lie too, because if your operating environment does have a concept of a NULL pointer, who is to say that skape hasn't already changed the exception handler that a null dereference will trigger, and make it do something mean :) Oddly, null pointer bugs seemingly retained 'unexploitable' status for over a decade after the first public exploit: http://packetstorm.linuxsecurity.com/poisonpen/8lgm/ptchown.c -JG From molney at sourcefire.com Thu Oct 8 21:26:22 2009 From: molney at sourcefire.com (Matt Olney) Date: Thu, 8 Oct 2009 21:26:22 -0400 Subject: [Dailydave] Exploits matter. In-Reply-To: <7abc832d0910081751h7f2e36fep8f9faf1b83aa6483@mail.gmail.com> References: <20091006151332.2BD2C3432D@absinthe.tinho.net> <4ACC7C1C.2090405@immunityinc.com> <77e259cc0910070624h44e3282fm4e11df822ba65dc7@mail.gmail.com> <7abc832d0910081751h7f2e36fep8f9faf1b83aa6483@mail.gmail.com> Message-ID: <77e259cc0910081826q5de99af4x7af853691e78a432@mail.gmail.com> OK...exploits are hard to develop. But that doesn't make defense easier. In fact, I would anticipate it making it much, much harder. As the bar raises, the organizations that can field the kind of expertise that can correctly interpret the impact of various vulnerabilities will shrink. Many of those remaining (certainly not all) will have a significant motivation not to share their information (gov/mil/ngo/criminal). This will make the problem of evaluating and prioritizing patching even more of an issue. I would also think that this might shift more of the burden to software vendors, as an increasing percentage of disclosures will come in the form of "in-the-wild" 0-day. Users are then at the mercy of software vendors to quickly and accurately patch issues. I think its clear from the behavior of several vendors over the past year that we have a long way to go in improving that response. In some cases, a very long way. Matt On Thu, Oct 8, 2009 at 8:51 PM, Fuzzy Hoodie-Monster wrote: > On Wed, Oct 7, 2009 at 6:24 AM, Matt Olney wrote: > >> Or, as I often put it, defense sucks. > > Except that Dave started this thread by saying how much harder it was > to develop this exploit than in the old days. > From jlloret at dcom.upv.es Sat Oct 10 14:37:55 2009 From: jlloret at dcom.upv.es (Jaime Lloret_Mauri) Date: Sat, 10 Oct 2009 20:37:55 +0200 Subject: [Dailydave] [NPA] Call for Papers: International Journal of Network Protocols and Algorithms Message-ID: <200910101837.n9AIbsqQ003957@smtp.upv.es> ********************* Call for Papers for Vol 1, Issue 2 ********************* Network Protocols and Algorithms ISSN 1943-3581 http://www.macrothink.org/journal/index.php/npa/ Network Protocols and Algorithms is a free online international journal, peer-reviewed and published by Macrothink Institute. It publishes papers focused on the design, development, manage, optimize or monitoring any type of network protocol, communication system, algorithm for communication and any protocol and algorithm to communicate network devices in a computer network. The scope of the journal include, but are not limited to, the following topic areas: - Synchronization Protocols and Algorithms - Security Protocols and Algorithms - QoS Protocols and Algorithms - Ad-Hoc and Sensor Network Protocols and Algorithms - Content Delivery Networks Protocols and Algorithms - P2P Protocols and Algorithms - Cluster-Based Protocols and Algorithms - Real-Time Protocols and Algorithms - Wireless Protocols and Algorithms - MAC Protocols and Algorithms for Wired Networks - Mobile wireless internet protocols and algorithms - Delay Tolerant protocols and algorithms - Mesh network protocols and algorithms - Protocols and algorithms for Voice over IP delivery - Cognitive Radio Network Protocols and Algorithms - Monitoring and management protocols and algorithms - optical networking protocols and algorithms - Scalable Network Protocols and Algorithms - Protocols and algorithms for Green Computing and Resource Allocation - Routing Protocols and Algorithms - Tree-based Protocols and Algorithms - Distributed/Decentralized Algorithms for Networks - Fault tolerant Protocols and Algorithms - Protocols and algorithms for Mobile and Dynamic Networks - Cross-Layer Collaborative Protocols and Algorithms - Formal methods and cryptographic algorithms for communication You are welcome to submit a paper or forward this call for papers to any people working in Network Protocols and Algorithms that may be interested in submitting a paper. The topics suggested by the journal can be discussed in term of concepts, state of the art, standards, implementations, running experiments and applications. Proposals and deployments are also welcome. Important Dates for the second Issue: _ Manuscript Due: November 15, 2009 _ Notification: December 13, 2009 _ Final Manuscripts Due: December 23, 2009 _ Tentative Publication: End of December 2009 Submission Information: Only original and unpublished research papers will be considered in this journal. Manuscripts must be writen in English. All submissions will be reviewed based on technical merit and relevance. Instructions for authors and submissions can be found in http://www.macrothink.org/journal/index.php/npa/about/submissions Jaime Lloret Mauri Editor in Chief of the International Journal of Network Protocols and Algorithms Associate Professor Department of Communications Polytechnic University of Valencia From dr at kyx.net Fri Oct 16 18:29:26 2009 From: dr at kyx.net (Dragos Ruiu) Date: Fri, 16 Oct 2009 15:29:26 -0700 (PDT) Subject: [Dailydave] CanSecWest 2010 CALL FOR PAPERS (deadline Nov 30, conf. Mar22-26) and PacSec (Nov 4/5) Selections Message-ID: <20091016222926.8D67B743A0@mail.kyx.net> We extend our apologies if you are inconvenienced by multiple copies of this messages. We would like to announce the PacSec 2009 Paper Selections, and the opening of the 2010 CanSecWest Call For Papers. Given the proximity of the Winter Olympics in Vancouver one month before the conference, we would advise all planning to attend to make travel preparations well in advance for next year... PacSec 2009 Presentations Keynote Presentation November 4: Mitsugu Okatani, National Information Security Center / Ministry of Defense / Japan Air Self-Defense Force Keynote Presentation November 5: Hideaki Kobayashi, Information Technology Promotion Agency Virtualisation security and the Intel privilege model - Tavis Ormandy & Julien Tinnes, Google Silicon Chips: No More Secrets - Karsten Nohl Filter Resistant Code Injection on ARM - Yves Younan, University of Leuven iPhone SMS Fuzzing and Exploitation - Charlie Miller, Independent Security Evaluators The Microsoft View of the 2008 Threat Landscape - Tony Lee, Microsoft Cloud Defense in the Post-BotWar Era - Ikuo Takahashi The Android Security Story: Challenges and Solutions for Secure Open Systems - Rich Cannings & Alex Stamos, Google, iSec Partners Stealthy Rootkit : How malware fools live memory forensics - Tsukasa Ooi, Livegrid Defending a Social Network - Alex Rice, Facebook Museum of API Obfuscation on Win32 - Masaki Suenaga, Symantec !exploitable and Effective Fuzzing Strategies as a Regular Part of Test - Jason Shirk, Microsoft Analyzing Word and Excel Document Encryption - Eric Filiol, ESIEA - Operational cryptology and Virology Lab English Dojo: Auditing Java Security, Marc Schoenefeld Japanese Dojo: Assembler Programming and Reverse Engineering Malware, Yuji Ukai, fourteenforty Pacsec will be held on November 4 and 5th, in Aoyama, Tokyo. CanSecWest 2010 CALL FOR PAPERS VANCOUVER, Canada -- The eleventh annual CanSecWest applied technical security conference - where the eminent figures in the international security industry will get together share best practices and technology - will be held in downtown Vancouver at the the Sheraton Wall Centre on March 22-26, 2010. The most significant new discoveries about computer network hack attacks and defenses, commercial security solutions, and pragmatic real world security experience will be presented in a series of informative tutorials. The CanSecWest meeting provides international researchers a relaxed, comfortable environment to learn from informative tutorials on key developments in security technology, and collaborate and socialize with their peers in one of the world's most scenic cities - a short drive away from one of North America's top skiing areas. The CanSecWest conference will also feature the availability of the Security Masters Dojo expert network security sensei instructors, and their advanced, and intermediate, hands-on training courses - featuring small class sizes and practical application excercises to maximize information transfer. We would like to announce the opportunity to submit papers, and/or lightning talk proposals for selection by the CanSecWest technical review committee. This year we will be doing one hour talks, and some shorter talk sessions. Please make your paper proposal submissions before November 30th, 2009. Some invited papers have been confirmed, but a limited number of speaking slots are still available. The conference is responsible for travel and accomodations for the speakers. If you have a proposal for a tutorial session then please make your submission using our new online form, available at https://cansecwest.com/submissions/. If the on-line form is not available you can alternatively email a synopsis of the material and your biography, papers and, speaking background to secwest09 [at] cansecwest.com . Only slides will be needed for the March paper deadline, full text does not have to be submitted - but will be accepted if available. This year we will be opening up the presentation guidelines to include talks not in English which we will offer to translate for the speaker if they are not a native English speaker. The CanSecWest 2010 conference consists of tutorials on technical details about current issues, innovative techniques and best practices in the information security realm. The audiences are a multi-national mix of professionals involved on a daily basis with security work: security product vendors, programmers, security officers, and network administrators. We give preference to technical details and new education for a technical audience. The conference itself is a single track series of presentations in a lecture theater environment. The presentations offer speakers the opportunity to showcase on-going research and collaborate with peers while educating and highlighting advancements in security products and techniques. The focus is on innovation, tutorials, and education instead of product pitches. Some commercial content is tolerated, but it needs to be backed up by a technical presenter - either giving a valuable tutorial and best practices instruction or detailing significant new technology in the products. Paper proposals should consist of the following information: 1. Presenter, and geographical location (country of origin/passport) and contact info (e-mail, postal address, phone, fax). 2. Employer and/or affiliations. 3. Brief biography, list of publications and papers. 4. Any significant presentation and educational experience/background. 5. Topic synopsis, Proposed paper title, and a one paragraph description. 6. Reason why this material is innovative or significant or an important tutorial. 7. Optionally, any samples of prepared material or outlines ready. 8. Will you have full text available or only slides? 9. Language of preference for submission. 10. Please list any other publications or conferences where this material has been or will be published/submitted. 11. If you have multiple speakers, please outline why each presenter is necessary and what each is presenting. Please include the plain text version of this information in your email as well as any file, pdf, sxw, ppt, or html attachments. Please forward the above information to secwest09 [at] cansecwest.com or use our on-line submissions form at https://cansecwest.com/submissions/ to be considered for placement on the speaker roster, or have your lightning talk scheduled. If you contact anyone else at our organization please ensure you also cc the submission address with your proposal or use the on-line submissions system or else it may be omitted from the review process. thanks, --dr P.S. please accept my apologies if your submission feedback hasn't arrived yet from PacSec (but no news is good news for a few which will be invited to Vancouver ;-). -- World Security Pros. Cutting Edge Training, Tools, and Techniques Tokyo, Japan November 4/5 2009 http://pacsec.jp Vancouver, Canada March 22-26 2010 http://cansecwest.com Amsterdam, Netherlands, June 16/17 2010 http://eusecwest.com pgpkey http://dragos.com/ kyxpgp From crioux at noctem.org Sun Oct 18 22:34:10 2009 From: crioux at noctem.org (Christien Rioux) Date: Sun, 18 Oct 2009 22:34:10 -0400 Subject: [Dailydave] SOURCE Boston 2010 Call for Papers In-Reply-To: <00ad01ca5053$1215d9d0$36418d70$@com> References: <00ad01ca5053$1215d9d0$36418d70$@com> Message-ID: <5680af290910181934l52435d51g7c99ac9105f5eab8@mail.gmail.com> SOURCE Boston 2010 Call for Papers is Now Open! SOURCE Boston 2010 April 21-23, 2010 Seaport Hotel www.sourceconference.com SOURCE is the first and only conference combining advanced technology and security practices with the business of security. With thoughtful attention to detail and emphasis on high quality and compelling technical content, SOURCE is committed to delivering valuable information in a high energy and fun environment. SOURCE is designed for advanced security professionals, faculty and students, and company executives, with a mission to integrate the technology and business of security. CFP Process Please complete the CFP form found on our website - http://www.sourceconference.com/index.php/boston2010/call-for-papers Information about SOURCE Boston Tracks - 50 minutes SOURCE attendees will experience two and a half days of intense 50 minute sessions taught by top security experts. Sessions hold 50-60 students, providing an intimate environment where attendees can ask questions, participate in discussions, and interact with each other and with speakers. Track 1: Security and Technology - Talks pertaining to new security technologies, security software, and engineering issues surrounding security. New software releases and live demonstrations are preferred. Track 2: Application Security - Software problems, coding practices, and engineering issues surrounding security. Track 3: Business and Security - Talks pertaining to the security industry and critical decision-making. Entrepreneurship, issues of compliance, regulation, privacy laws, exploit research and disclosure, and economics. What We Will NOT Accept * Submissions from PR agencies, in-house PR or marketing professionals * Presentations that focus on marketing or directly promoting a company's products * Generic presentations that do not offer any new perspectives or insight What DO We Look For * New research, technologies and releases * Unique perspectives into the security industry * Synergies between technology and business * Live demonstrations * Solutions-based presentations or new approaches to solving problems * It is preferred that SOURCE Boston 2010 speaking abstracts are ORIGINAL content and have not be presented or duplicated at any other security or networking conference prior to April 21-23, 2010. Call for Papers Committee The Call For Papers Committee is comprised of the following individuals: Rob Cheyne, Safelight Security Advisors John Cran, Rapid7 Chris Eng, Veracode Jamie Fullerton, Microsoft Raffael Marty, PixlCloud Val Smith, Attack Research Dov Yoran, MetroSITE Group Important Dates CFP Closes ? January 15, 2010 Notification Deadline ? January 25, 2010 Final Bio/Abstract & Slides Deadline ? April 1, 2010 Speaker Privileges Free access to the conference plus half off an additional ticket Two nights in a deluxe room with city or water view at one of downtown Boston?s most popular hotels; travel expenses paid if possible* Earn money by participating in the SOURCE Commission Program Participate in an invitation-only speaker discussion group Invitation to Speaker/Sponsor Reception *Organizations that sponsor a speaker?s travel will be given a complimentary speaker sponsorship Sponsorship The SOURCE Boston 2010 sponsorship kit is available. Please email ?sponsor at sourceconference dot com? Registration $795 Early Bird Registration $995 February 1st - April 1, 2010 $1195 April 1st, 2010 - at door $125 - Student Registration Economy Registration Discount Rate ?- $495. ~~ LIMITED TO 100 REGISTRATIONS ~~ To assist security professionals during this time of economic hardship, SOURCE Boston provides an Economy Registration Discount. For the discounted price of $495, security professionals can attend all sessions, the exhibit hall, the security showcase, and the exhibit hall reception.? However, this cost does NOT include any meals or drinks (besides coffee). Questions regarding the conference may be sent to ?info at sourceconference dot com? Conference Manager: Stacy Thayer, Ph.D. From dave at immunityinc.com Wed Oct 21 17:14:01 2009 From: dave at immunityinc.com (dave) Date: Wed, 21 Oct 2009 17:14:01 -0400 Subject: [Dailydave] Solvers! Message-ID: <4ADF7999.6090905@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm trying to get a django app built so I can demo some of our new tech, but it's slow going. In the meantime today's extra credit reading and viewing: http://seanhn.wordpress.com/ (solver->exploits blog and paper) http://media.blackhat.com/bh-usa-06/video/2006_BlackHat_Vegas-V7-Halvar_Flake-Need_New_Tools.mp4 That's probably Halvar's best talk - in it he chats about solving input crafting issues with large equation solvers (from 2006 so will perhaps bust some evil software patents, if that's your sort of thing). But in general, just worth a second viewing. - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkrfeZkACgkQtehAhL0ghepuPACZAdeYsAH6tkM6ww3aej9NgZ+d m2cAn033RGHOsnDwM7PfpYVeAJByjCx7 =i6+r -----END PGP SIGNATURE----- From version5 at gmail.com Thu Oct 22 08:40:59 2009 From: version5 at gmail.com (nnp) Date: Thu, 22 Oct 2009 13:40:59 +0100 Subject: [Dailydave] Solvers! In-Reply-To: <4ADF7999.6090905@immunityinc.com> References: <4ADF7999.6090905@immunityinc.com> Message-ID: <28749c0e0910220540y2855fdaega562c34e775657f3@mail.gmail.com> The architecture and design of the basic algorithm behind most solvers we use for input generation was first described in 1960 (the DPLL algorithm) so I think we're safe from the patent mongers there ;-) As for the logic-specific parts of the solvers, most are described in academic papers spanning the last 40 years so I presume that constitutes 'prior art'. I don't know of anybody working on designing or implementing the modern crop of SMT solvers that has tried to, or intends to try to, patent their algorithms but if I'm wrong I'd be interested to hear. Patenting that sort of work can never be good. All of the leading solvers are available for download here http://www.smtexec.org/exec/?jobs=529 , in case anyone wants to go play. On Wed, Oct 21, 2009 at 10:14 PM, dave wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I'm trying to get a django app built so I can demo some of our new tech, > but it's slow going. In the meantime today's extra credit reading and > viewing: > > http://seanhn.wordpress.com/ (solver->exploits blog and paper) > > http://media.blackhat.com/bh-usa-06/video/2006_BlackHat_Vegas-V7-Halvar_Flake-Need_New_Tools.mp4 > > That's probably Halvar's best talk - in it he chats about solving input > crafting issues with large equation solvers (from 2006 so will perhaps > bust some evil software patents, if that's your sort of thing). But in > general, just worth a second viewing. > > - -dave > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iEYEARECAAYFAkrfeZkACgkQtehAhL0ghepuPACZAdeYsAH6tkM6ww3aej9NgZ+d > m2cAn033RGHOsnDwM7PfpYVeAJByjCx7 > =i6+r > -----END PGP SIGNATURE----- > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > From jericho at attrition.org Thu Oct 22 21:25:44 2009 From: jericho at attrition.org (security curmudgeon) Date: Fri, 23 Oct 2009 01:25:44 +0000 (UTC) Subject: [Dailydave] Exploits matter. In-Reply-To: <5c2b0f0b0910071715g170761c3lad393efa06fefe28@mail.gmail.com> References: <20091006151332.2BD2C3432D@absinthe.tinho.net> <4ACC7C1C.2090405@immunityinc.com> <5c2b0f0b0910071635i56b62b1exddcbe78554556dc7@mail.gmail.com> <5c2b0f0b0910071715g170761c3lad393efa06fefe28@mail.gmail.com> Message-ID: Based on discussion from this thread and internal chat: http://blog.osvdb.org/2009/10/22/classification-exploit-status-overhaul# Classification: Exploit Status Overhaul Posted by jericho 31 minutes ago OSVDB's classification system is designed to categorize certain attributes of a vulnerability. This facilitates custom searches by a specific attribute, helps researchers develop metrics and gives a better picture of the vulnerability landscape. Until now, we've tracked if an exploit is 'available', 'unavailable', 'rumored / private' or 'unknown'. While this was a good start for exploit status, it has quickly outgrown usefulness. Today, OSVDB overhauled the exploit classification to use the following: * exploit public - A working exploit is publicly available. * exploit rumored - An exploit is rumored to exist, but cannot be confirmed. * exploit private - An exploit exists, but is not available to the public or in a commercial framework (e.g., vulnerability pre-disclosure groups like iDefense or ZDI, researcher developed but unreleased). * exploit commercial - An exploit has been created and is available to customers in a commercial framework such as Canvas or CORE Impact. * exploit unknown - The status of a working exploit is unknown. In addition, we are moving one existing classification to the 'exploit' column since it is relevant to this category: * exploit wormified - An exploit has been crafted to spread via 'worm' or 'virus'. As always, if you have suggestions or questions about the classification system, please mail moderators[at]osvdb.org! From dave at immunityinc.com Fri Oct 23 16:42:59 2009 From: dave at immunityinc.com (dave) Date: Fri, 23 Oct 2009 16:42:59 -0400 Subject: [Dailydave] Friday afternoon RAND fail. :> Message-ID: <4AE21553.40007@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - From Rand's new whitepaper on Cyberwarfare (pg. 73): http://www.rand.org/pubs/monographs/2009/RAND_MG877.pdf """ The following hints may be indicative. Private hackers are more likely to use techniques that have been circulating throughout the hacker community. While it is not impossible that they have managed to generate a novel exploit to take advantage of a hitherto unknown vulnerability, they are unlikely to have more than one. """ - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkriFVMACgkQtehAhL0ghep2VQCggLX5e9C4Rs4fTl+3MUBphoEp YW0AoIeP7gtzu9VHw4YaZ9iQQviEgyVB =LWRX -----END PGP SIGNATURE----- From gunter at damballa.com Fri Oct 23 18:22:04 2009 From: gunter at damballa.com (Gunter Ollmann) Date: Fri, 23 Oct 2009 22:22:04 +0000 (UTC) Subject: [Dailydave] Friday afternoon RAND fail. :> In-Reply-To: <4AE21553.40007@immunityinc.com> References: <4AE21553.40007@immunityinc.com> Message-ID: <0e2e01ca542f$d3ce01d0$7b6a0570$@com> Who writes this kind of drivel? While I'm sure there may be arguments for and against a statement like that are going to be plentiful, this sounds so uninformed IMHO. I obviously don't believe that statement to be true; not now or in the future. It would be naive to believe so, and dangerous to base actions on a conclusion like this. With that in mind you'll probably note the Rand statement on page two "All RAND monographs undergo rigorous peer review to ensure high standards for research quality and objectivity." -- Really? I wonder what the monograms that don't undergo peer review say. -- Gunter -----Original Message----- From: dailydave-bounces at lists.immunitysec.com [mailto:dailydave-bounces at lists.immunitysec.com] On Behalf Of dave Sent: Friday, October 23, 2009 4:43 PM To: dailydave at lists.immunityinc.com Subject: [Dailydave] Friday afternoon RAND fail. :> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - From Rand's new whitepaper on Cyberwarfare (pg. 73): http://www.rand.org/pubs/monographs/2009/RAND_MG877.pdf """ The following hints may be indicative. Private hackers are more likely to use techniques that have been circulating throughout the hacker community. While it is not impossible that they have managed to generate a novel exploit to take advantage of a hitherto unknown vulnerability, they are unlikely to have more than one. """ - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkriFVMACgkQtehAhL0ghep2VQCggLX5e9C4Rs4fTl+3MUBphoEp YW0AoIeP7gtzu9VHw4YaZ9iQQviEgyVB =LWRX -----END PGP SIGNATURE----- _______________________________________________ Dailydave mailing list Dailydave at lists.immunitysec.com http://lists.immunitysec.com/mailman/listinfo/dailydave From leddown at yahoo.com Fri Oct 23 18:55:14 2009 From: leddown at yahoo.com (Travis Carelock) Date: Fri, 23 Oct 2009 15:55:14 -0700 (PDT) Subject: [Dailydave] Friday afternoon RAND fail. :> In-Reply-To: <4AE21553.40007@immunityinc.com> Message-ID: <152613.79441.qm@web30501.mail.mud.yahoo.com> I actually kind of agree with him.? I don't think that he writes this with the "Lions" that are on this list in mind.? He also makes the mistake of using the word "hacker" here.? But of the attackers out there in the world, the vast majority do use tools and techniques that they themselves did not come up with. ? If he does mean to say that the true Hackers don't have the goods... well then.... there is only so much you can teach people.? -t --- On Fri, 10/23/09, dave wrote: From: dave Subject: [Dailydave] Friday afternoon RAND fail. :> To: dailydave at lists.immunityinc.com Date: Friday, October 23, 2009, 3:42 PM -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - From Rand's new whitepaper on Cyberwarfare (pg. 73): http://www.rand.org/pubs/monographs/2009/RAND_MG877.pdf """ ? ? ? The following hints may be indicative. Private hackers are more likely to use techniques that have been circulating throughout the hacker community. While it is not impossible that they have managed to generate a novel exploit to take advantage of a hitherto unknown vulnerability, they are unlikely to have more than one. """ - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkriFVMACgkQtehAhL0ghep2VQCggLX5e9C4Rs4fTl+3MUBphoEp YW0AoIeP7gtzu9VHw4YaZ9iQQviEgyVB =LWRX -----END PGP SIGNATURE----- _______________________________________________ Dailydave mailing list Dailydave at lists.immunitysec.com http://lists.immunitysec.com/mailman/listinfo/dailydave -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20091023/b12ade03/attachment.htm From dave at immunityinc.com Mon Oct 26 11:35:52 2009 From: dave at immunityinc.com (dave) Date: Mon, 26 Oct 2009 11:35:52 -0400 Subject: [Dailydave] Friday afternoon RAND fail. :> In-Reply-To: <0e2e01ca542f$d3ce01d0$7b6a0570$@com> References: <4AE21553.40007@immunityinc.com> <0e2e01ca542f$d3ce01d0$7b6a0570$@com> Message-ID: <4AE5C1D8.9090402@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In related news, VulnDisco has Solaris 0day this month. https://forum.immunityinc.com/board/thread/63/vulndisco/?page=1#post-63 One of the people who did peer review for that RAND paper emailed me. I'll leave what he said private though. I'm sure the author (Martin C. Libicki) has had enough people annoying him over it this morning. :> - -dave Gunter Ollmann wrote: ... > With that in mind you'll probably note the Rand statement on page two "All > RAND monographs undergo rigorous peer review to ensure high standards for > research quality and objectivity." -- Really? I wonder what the monograms > that don't undergo peer review say. > > -- Gunter > > -----Original Message----- > From: dailydave-bounces at lists.immunitysec.com > [mailto:dailydave-bounces at lists.immunitysec.com] On Behalf Of dave > Sent: Friday, October 23, 2009 4:43 PM > To: dailydave at lists.immunityinc.com > Subject: [Dailydave] Friday afternoon RAND fail. :> > > From Rand's new whitepaper on Cyberwarfare (pg. 73): > > http://www.rand.org/pubs/monographs/2009/RAND_MG877.pdf > > """ > The following hints may be indicative. Private hackers are more > likely to use techniques that have been circulating throughout the > hacker community. While it is not impossible that they have managed > to generate a novel exploit to take advantage of a hitherto unknown > vulnerability, they are unlikely to have more than one. > """ > > -dave _______________________________________________ Dailydave mailing list Dailydave at lists.immunitysec.com http://lists.immunitysec.com/mailman/listinfo/dailydave _______________________________________________ Dailydave mailing list Dailydave at lists.immunitysec.com http://lists.immunitysec.com/mailman/listinfo/dailydave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkrlwdgACgkQtehAhL0gheqYZQCghGGZep6RRbFHEgrS7JRh0VQO QtAAn0kZlTmZXM7Y/ho2HJ/pOY2mzqj9 =xzEU -----END PGP SIGNATURE----- From jlloret at dcom.upv.es Mon Oct 26 18:36:17 2009 From: jlloret at dcom.upv.es (Jaime Lloret Mauri) Date: Mon, 26 Oct 2009 23:36:17 +0100 Subject: [Dailydave] Last mile || InfoSys 2010 [ICAS, ICNS, INTENSIVE, LMPCNA] March 7-13, 2010 - Cancun, Mexico Message-ID: <200910262236.n9QMaHbQ011868@smtp.upv.es> Last mile || InfoSys 2010 [ICAS, ICNS, INTENSIVE, LMPCNA] March 7-13, 2010 - Cancun, Mexico INVITATION Note that we are entering the last few days of submission for the events collocated in Cancun, Mexico Please consider to contribute and encourage your team members and fellow scientists to contribute to the following federated events. The submission deadline has now been moved to November 1, 2009. Publisher: CPS ( see: http://www2.computer.org/portal/web/cscps ) Archived: IEEE CSDL (Computer Science Digital Library) and IEEE Xplore Submitted for indexing: Elsevier's EI Compendex Database, EI?s Engineering Information Index Thanks for forwarding the information on this Call for Submissions to those potentially interested to submit. ===== Call for Submissions ======= InfoSys 2010, March 7-13, 2010 - Cancun, Mexico see: http://www.iaria.org/conferences2010/InfoSys10.html InfoSys 2010 is a federated event focusing on advances topics concerning the networks, systems, autonomy, and learning methodologies. InfoSys 2010 continues the tradition of well-established conferences ICAS, ICNS, the LMPCNA workshop, and second edition of INTENSIVE. Submission (full paper) new deadline: November 1, 2009. Submissions must be electronically done using the 'Submit a Paper' link on the entry page of each conference. Before submission, please check and conform with the Editorial rules: http://www.iaria.org/editorialrules.html. For details on the each conference's topics, see the individual Call for Papers for each conference. Unpublished high quality contributions in terms of Regular papers and Posters or Work in Progress are welcome. Workshop proposals and Panel proposals on challenging topics are encouraged. Extended versions of selected papers will be published in IARIA on-line Journals (http://www.iariajournals.org) and in Special issues of different journals mentioned on the entry page of each conference. Submissions will be peer-reviewed, published by IEEE Computer Society Press, posted in IEEE Digital Library, and indexed via all the IEEE indexing agreements. All tracks/topics are open to both research and industry contributions. -- ICNS 2010, The Sixth International Conference on Networking and Services http://www.iaria.org/conferences2010/ICNS10.html -- ICAS 2010, The Sixth International Conference on Autonomic and Autonomous Systems http://www.iaria.org/conferences2010/ICAS10.html -- INTENSIVE 2010, The Second International Conference on Resource Intensive Applications and Services http://www.iaria.org/conferences2010/INTENSIVE10.html -- LMPCNA 2010, The Second International Workshop on Learning Methodologies and Platforms used in the Cisco Networking Academy http://www.iaria.org/conferences2010/LMPCNA.html ----------------------- IARIA Publicity Board ----------------------- From dave at immunityinc.com Tue Oct 27 11:09:40 2009 From: dave at immunityinc.com (dave) Date: Tue, 27 Oct 2009 11:09:40 -0400 Subject: [Dailydave] B. Aggressive. B. E. Aggressive. (or "One 0day is enough") Message-ID: <4AE70D34.1040105@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 When you go into security consulting engagements with a new business unit you usually face a few questions from the developers and business owners. "What is it exactly that you're going to tell us?" We always answer this the same way: "Things that will surprise you." Most developers have read a lot about security these days - they understand SQL Injection, Cross Site Scripting, access control, not to use their own cryptographics, and all sorts of other security truisms. What they can't possibly understand is how a hacker's mind works, and what they're likely to find. Even security specialists who have only worked defence often have never really seen a hacker go. Largely I think this is because there's a difference between someone playing cards with chips and someone with their house and life on the line. People say penetration testing is a model of an attacker. But how do you model obsession? - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkrnDTQACgkQtehAhL0ghepPdgCfVAz0n5rERBmfuE0sXA0ErYKf UtAAn2mWY0d6PoxYyYc6fanYCn10tj/8 =pWSW -----END PGP SIGNATURE----- From dave at immunityinc.com Wed Oct 28 13:27:26 2009 From: dave at immunityinc.com (dave) Date: Wed, 28 Oct 2009 13:27:26 -0400 Subject: [Dailydave] PrevX and other projects Message-ID: <4AE87EFE.9070101@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So you can read one Immunity deliverable linked here: http://www.prevx.com/ (look for "Independent Review"). Likewise, if you have wondered where all the Immunity Debugger scripts ran off to, they were on the old Immunity Forum. We ripped the old forum content out of the old database and imported into the new hotness, so you can seem them all here: https://forum.immunityinc.com/. I don't think Google spiders HTTPS sites for some reason which is annoying, but all the content is there if you're just learning how to use CANVAS or Immunity Debugger or something. You know what would be a killer mobile phone app? Something that implements a GPG-like web of trust with transparent encryption. Is there an app for that? - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkrofv4ACgkQtehAhL0ghergeQCcCeiuhczI45QKAFspLLRfnPkV 1fEAn1jv2MEyHtLqB8/bCKlIs+NX8Y15 =RT2+ -----END PGP SIGNATURE----- From shane at security-objectives.com Thu Oct 29 23:36:45 2009 From: shane at security-objectives.com (Shane Macaulay) Date: Thu, 29 Oct 2009 20:36:45 -0700 Subject: [Dailydave] PrevX and other projects In-Reply-To: <4AE87EFE.9070101@immunityinc.com> References: <4AE87EFE.9070101@immunityinc.com> Message-ID: <4AEA5F4D.9020507@security-objectives.com> The chart on their main page would be a lot more compelling if they had conversely applied whatever method they used to collect that information. """"These statistics are provided to show that all vendors miss threats and cannot be interpreted to compare the effectiveness of one product to another.""""" That seems to indicate they would show us their failure rate when compared to these vendors? And why in the anti-virii community is it OK to slam your competitors so hard? You do not see many Microsoft advisories about 3'rd party software or FreeBSD advisories about Apple kernel flaws (oh ya, @OpenBSD http://www.openbsd.org/errata46.html -- if you use the word attacker, it's not a reliability fix :), I digress. I skimmed Dave's report, it has nothing to do with the chart in question ;), and I'm sure this chart is really just FUD dressed up by some programmer (people programmers) marketing jock's. Dave: I think mobile phone wise, I'd imagine most people would default to an SSL mailer client, however, WOT wyse, I did see a silverlight (http://code.google.com/p/flextermshell/) SSH recently. Also with all of the prevalence of SSH in mobile phone's (this was the first killer-app afaik for those old Nokia communicator's) and generally how widespread ssh is in general, I think killer-app would be SSH based file encryption implementations (and associated asccii spec's for mail files). Why aren't their any SSHpgp app's? It would benefit everybody so much more, dump pgp, use ssh, SSH should expand into files and establish an anonymous establishment spec to obsolete SSL, it seems much more likely to catch on than HTTP+OpenGPG. Current SSH implementations already have all the bits to-do this and the natural way SSH could function accelerating/offloaded any secure communications from endpoints with the channel/multi-plexing functionality. Oh I forgot, it's impossible, where would the Internet be without the Verisign(tm), hegemony and who to pay homage? WOT is doomed for this reason. SSHTTP is sort of catchy though isn't it? ;) -- Shane dave wrote: > So you can read one Immunity deliverable linked here: > http://www.prevx.com/ (look for "Independent Review"). > > Likewise, if you have wondered where all the Immunity Debugger scripts > ran off to, they were on the old Immunity Forum. We ripped the old forum > content out of the old database and imported into the new hotness, so > you can seem them all here: > https://forum.immunityinc.com/. I don't think Google spiders HTTPS sites > for some reason which is annoying, but all the content is there if > you're just learning how to use CANVAS or Immunity Debugger or something. > > You know what would be a killer mobile phone app? Something that > implements a GPG-like web of trust with transparent encryption. Is there > an app for that? > > -dave _______________________________________________ Dailydave mailing list Dailydave at lists.immunitysec.com http://lists.immunitysec.com/mailman/listinfo/dailydave