Dan Kaminsky could have made hundreds of thousands of dollars with this DNS flaw!

Thomas Ptacek | July 8th, 2008 | Filed Under: Uncategorized

We interrupt this pile-on to bring you this important message: Dan has the goods. Patch now, ask questions later. More to come this evening.

Java JSESSIONID: BB16479A0338D3DCF26D11712F138BC1

.NET ASPESSIONID: HHODHGFDJOJAKDIPPJCKHGOE

SiteMinder SMESSIONID:

su/hxP2nLeaZBdEn8qClOdeCGwG2xfLaBfXQF2QpSCSxKYBLVTF7OfqtVcHxLITpuNa6+1W c2ZJ9MKWInlFlEe5GqZAjobgyzInCwe3JiTebqyJaftWtVht/La0qlvjLF9oaI5y1aIdtUGiTmQI OW28AL0gLJe4pdA0sw2fq4cBG8ZWPMblwX4nGCGXGU8JQ1PtOhm8ohtSQcXZ7lm35t29 P5tcbfDrQs3z4g43zrLRO5M68m91xP7xcHY0uLuSYUSMFIrUbaEVSVVewFY4tskjPYecoWT uLV0deSJilKpfSTVyekbzGXO2ejhIPxsE5cvPVNPt5AoJ6KIdvWMezUHz+KQt3uVuJEHpZkU QhEfLrWAdJ2TwE++na2G3GI8BqlSOB+KRl3rz19/9nqpE87c/IWsscSfOQLemzwd/Z3DZfn ioKB/tFsZWLndqdNq5XmDuRvRN2+EVMT8QFYEq1c+mNhsOIeFCjo8JOOXPG3F+r6h0kXN M4zjRtgN/qSYRAycXluqKozAIMgr5qemW1UItwCyqJu1cDMLuKgkSq9XXA3Cru6PVPF74D1 t8l2IvV2HWmxL2PP4RdIXa5Ofb1sCLc6AUZ9opLGhwYHt7S3PnxXzKoYsMJwoFm7nGqjKp J7S9e0iRTMUqY7fOgSQALLw+hsac7hhNCUtB3/xEhvfJ7Y4b1Xj26jWJAujEnHgF+DUJQHvX hkLl7Rr2dbCPJu/8hDMOKdfz4QJXAQSbCJyA4MrJLXn4UZLpgwMeIVMddvloO4dZatrxQT9m ZQtqvow5jKcpUKhtxqqf7M4MFDMOEvQdIT3U8WRsbjk1lT4UajljxyTa9TSF9sCid1BH/O3Hq YyJtfpDcr7QxqHXr9AZYtHbO93DX/I82bQ3mcCco

DNS XID: 04d8

Getting To File This Week’s Front Page Security Story Before Changing Out Of Your Pajamas: Priceless.

There are some vulnerabilities money can’t buy. For everything else: there’s the DNS.

Viewing 59 Comments

    • ^
    • v
    Cache poisoning ?
    • ^
    • v
    Are you trying to convey to us how easy it is to poison a DNS server by using relative length in strings?
    • ^
    • v
    Its hard to tell what new flaw in XID randomization Kaminsky found which wasn't pointed out by Amin Klein, who has been researching XID randomization in various implementations.

    I heard birthday attack wording here.
    • ^
    • v
    http://blogs.zdnet.com/security/?p=1468 :

    X <- Matasano Blog Entry
    .
    .
    . <- whooosh area
    .
    .
    O <- Nathan's head
    |
    /\
    • ^
    • v
    in other news, Dan Kaminsky reads rfc 3833, takes credit, spreads FUD and causes many stupid news articles to be written.
    • ^
    • v
    Thom! Your blog will have a big day today, since I will reveal Dans secret here! (Actually this is the blind guess, but it definitely should have some truth here.)

    Key theory behind this is: We would have more chances to poison DNS cache if we would spoof million query RESPONSES with CONSTANT XID for million REQUESTS with RANDOM XID, than spoofing ~1000 RESPONSES with RANDOM XID for one RANDOM XID request. (approx 1k responses because we assume that we can send ~1000 fake responses packets before legitimate dns server answer).

    Do you agree with this? Then lets continue to see how to accomplish that.

    Seeing how Dan thinks, the key lies in CLIENT SIDE (think browser):
    So the VICTIM opens page where there are million to force user make these million queries while performing spoofing with CONSTANT XID in spoofed response.

    By here you should start think: what does *.attacker.controlled.host has to do with dns.to.spoof.com? Well, I haven't figured out that jet, but I think it has something to do with that CNAME shit which Dan likes so much.

    And if this is true and this post gets world media attention, then I would like to greet r0t, r21vo, saime and other script kiddies from Latvia!!!111 lol.
    • ^
    • v
    *yawn* .. here comes the onslaught of interviews and media explosion for another overhyped bug by dan kaminsky. maybe this will make up the slack for his horrible book
    • ^
    • v
    Can't speak to his latest book, but his work at University of Cleveland was unimpeachable.

    http://www.amazon.com/Microbiology-multiple-que...

    Helped me pass my nursing exam.
    • ^
    • v
    All I'm saying is that in 2008, it is ridiculous that JBoss defaults to a 128 bit cookie, but the DNS protocol relies on a 16 bit XID.
    • ^
    • v
    If all I've done here is gotten people to patch up to the level DJBDNS achieved years ago, it'd still be worth it.

    There's more, of course. But if you don't think there is, you have to at least admit that it's pretty cool to have the old stuff fixed. So, just imagine there's some crazy reason why now finally people are taking RFC 3833 and DJB seriously.

    Here's to no more crappy name servers, for whatever reason.
    • ^
    • v
    3833 wasn't published until 2004. That's *after* the birthday+duplicates attack. If you take any RFC seriously anymore, you're a sucker. The Internet is what the vendors and developers say it is.
    • ^
    • v
    Why don't we just let this play out at BH. Internal bickering just makes the entire community look bad. If Dan doesn't have anything new, there's plenty of time to skewer him, even though a lot of good still came out of this.
    • ^
    • v
    Dan is the one who decided to start discussing this issue, whatever it may be, prior to BH - why should those in the community not speculate about what he has (or hasn't) found?
    • ^
    • v
    Jeremy--

    Man, I know it's a big ask not to speculate publicly.

    I know this.

    But I'm trying to help the good guys here. Some of the smartest people I know hang out here -- your musings don't have to be published here too.

    Look at it from my perspective: I've got some stuff -- maybe good, maybe bad, but I don't think there's any doubt that there's something -- but, to help the good guys, I have to remain silent. I have to subject myself to a lot of attacks, from people who are speculating. People who don't know what's up.

    And that's OK. If the cost of protecting users, is that some people think there's nothing new to protect users against -- then I'm cool with that. We all respect DJB. We all know the birthday attacks sucked. Amit's stuff is real. This patch fixes all of it. That work was deeply overdue.

    And, when Black Hat comes out -- I'll lay it all out on the table, and everyone can judge. There's an open offer to Ptacek -- I will mail him the slides at the beginnning of my talk, and whatever he thinks of them, he can put in a slide and that will be how I will end my presentation.

    I'm trying to protect users. I'm asking for your help.
    • ^
    • v
    "Man, I know it’s a big ask not to speculate publicly."

    "your musings don’t have to be published here too."

    so you ask the people with a clue not to speculate so your talk isn't blown but then you whore out minor details and FUD to everyone newspaper/magazine/publishing house so that your name can go all over google and gain 5 minutes of fame? This is why people hate you and wish you would work at McDonalds instead.
    • ^
    • v
    Dan: I don't hate you and wish you worked at McDonalds, but after that blog post I can see where people are coming from. When people stop needing protecting PRECISELY WHEN YOUR BLACK HAT TALK is on, it's really hard not to paint a picture.

    I'm going to suggest, once again, that you just be up front: you did good work, you want to present it on your terms. Those of us who've been in those shoes will understand that.

    But hey, I've taken my hits for running my mouth too. Sometimes it's worth it. Your call!
    • ^
    • v
    Are you the Tom Ptacek whose brothers are Chris and Steven?
    • ^
    • v
    Security research is built on open discussion, and people taking a critical view of what is and isn't a flaw, what constitutes a good patch, so on and so forth. I feel like most of what we do is a direct result from the days when companies silently patched security issues, or tried to stifle the discussion of them.

    Are you asking to go back to the days of the good ol' boys security club? Back when people talked on private mailing lists like Zardoz? When "someone" decided who was and wasn't qualified and responsible enough for information?

    You can't have it both ways. You've benefited from people openly discussing their findings, and now you're asking people to not discuss whatever you found? Had DJB, Amit Klein, etc not made their findings public, would we be having this discussion?

    Finally, I'd like you to recant your statement that DJB is a lucky programmer. I think all of us can agree that his material on forgery clearly indicates that is not that case. He recognized that 16-bit XID's were insufficient, identified other vulnerabilities in bind that further reduced the complexity in forgery, and implemented a fix in djbdns to address the real problem (16-bit XID's, for those taking notes).
    • ^
    • v
    El Reg says some kid found this while studying for his SANS GIAC.

    http://www.theregister.co.uk/2008/07/09/dns_bug...

    I found Sotirov's Heap Feng Shui attack myself, while working on my A+ last year, but I wrote it down on the back of a massage parlor receipt that I put through a cross-cut shredder. Identity theft is no joke, kids!
    • ^
    • v
    Eh, you guys realize that djb pointed this out over 6 years ago?
    • ^
    • v
    PDP
    Kaminsky

    welcome to Security 2.0...

    It is all about media manipulation to hype own bugs.

    I am so tired about this responsible disclosure (enlarge media attention) bullshit by guys who sell bugs to the government or worse...
    • ^
    • v
    dirty: YES.
    • ^
    • v
    @ Bliblablub:
    I agree ... if pdp, kaminsky, and gadi would never work in sec again the industry would become 100x overnight
    • ^
    • v
    It is not fair to compare a vulnerability researcher to Gadi Evron. Two different things.
    • ^
    • v
    youfail,

    The public doesn't need minor details. The public does however need notification, and enough of eat to break through the everyday noise. Have you spent any time in corporate environments? Change is expensive. I'm asking people to sit through boring meetings and fix something that doesn't look broken. These are people who have no idea who the hell I am, as opposed to most people here who I've probably thrown back a shot with. These people react to bandwagons, and in a very real sense, to an implication that they should have known this was a problem.

    This is the best way of making sure people should have known there was a problem, without spawning a full on crisis. The best thing possible would be for there to be no flaw. Barring that, this is the second best. I am totally open to new ideas however. Really, I've never done anything like this before.

    Tom,

    I can't give this talk without warning, because the bugs are quite bad. I also can't not give this talk, because then I'd be calling the credibility of the entire community into question, and everyone would be right to rip the vulnerability out into the open (or declare it irrelevant and unworthy of patch) immediately.

    So, I've got me a rock, and I've got me a hard place. I'm asking for a third option. I will bust it all out, and I will throw myself on the mercy of the security community to judge whether it was worth all the noise or not. But give me enough time, so that when I do so, the rest of the public doesn't completely freak out.

    Those are the terms I'm looking for -- full disclosure, lets just get people some warning to patch.

    Jeremy--

    The good ol' boys club sucks. It's a recipe for stagnation and irrelevance. We need the meritocracy to expose who's doing good work and frankly who isn't. But we also need the freedom to express our merits.

    So, I'd like a few weeks. I can't demand it. It's a lot to ask for. But it's not forever. It's a hard, solid date -- August 6th, 2008 -- and everyone can decide then if what I did was right or wrong. (Needless to say, I don't show, I deserve everything that would ever be thrown at me. I'm all in.) Just let me give this talk, on my terms. I've convinced the vendors, using language they understand. I'm convincing the public, using language they understand. On August 6th, give me the opportunity to disclose in the deepest technical voodoo I can muster. You let me know then if it was enough.

    As for DJB, you misunderstand. I'm saying there is no such thing as "luck" -- a master like DJB follows his design principles, and is more right than even he knows. We should all be as lucky as him.

    Statler--

    Cool! Another bug that this patch will fix. People should definitely apply to patch, to protect themselves from this student's attack.

    If all I've done here is make people more like DJB, I'd be happy.
    • ^
    • v
    Jeremy: If you're going to tear into Dan's blog post, link to it so the home viewers can follow along:
    http://www.doxpara.com/?p=1162

    Secondly, I arrive at a different interpretation than you do in Kaminsky calling DJB "lucky". Here's Kaminsky's opener: "Luck is the residue of design." aka luck favors the prepared.

    Re: timing. Did everyone notice that this came out on Microsoft's Patch Tuesday? Does that tell you anything about whose schedule everyone was working to? This was the last Patch Tuesday before Black Hat.

    Re: blood in the water. Researchers have to research. Good guys trying to corral vendors have to ask for time to patch. Smart people who don't like secrecy have to demonstrate they can figure it out on their own with the hints given. Everyone is doing their job.
    • ^
    • v
    Dan: your appeals to DJB would be more credible if you had mentioned him to any press outlet, anywhere. Got a URL?
    • ^
    • v
    Ryan: Ok. It's patch tuesday. It's patched. What's the pretense for a 30 day embargo on further research until Black Hat? And if it's important to keep this quiet, why the PR blitz?
    • ^
    • v
    Kaminsky: "I will throw myself on the mercy of the security community to judge whether it was worth all the noise or not."

    You're about to find out that the security community is capable of generating enough noise that it won't be worth it, no matter how good your stuff is.
    • ^
    • v
    Ryan: I appreciate that you're taking the opposing side of the argument, and your opinion is valuable, even when I disagree with it.

    But with that said: it's disingenuous in the extreme to say that it's the security community that's generating the noise. This story hit the BBC and the Chicago Tribune. Pick an argument you can win.
    • ^
    • v
    XID is an RPC thing isnt it? DNS has qIDs... or perhaps the terminology is now changed just to add confusion..

    qIDs have 16bits, not enough key space to avoid prediction/guessing NO MATTER WHAT. That has been clear and known "in theory" since the 1980s (search for Schuba and Spafford) and has been demonstrated in practice in 1996. Yeah,that's right, 12years ago, search for "res_random.txt". There's a reason why OpenBSD started to use something much closer to randomness than qid++ back then. There's also a reason why they choose not randomize the source port of every DNS query even tho. they been randomizing source ports -and many other things- for a lot similar purposes since the mid-90s.

    Since then several others actually improved the efficiency of DNS poisoning attacks that relied on the same protocol weakness (there have been and are poisoning attacks that rely on other weaknesses or bugs). As of now (pending Dan Kaminsky's disclosure) Amit Klein's is the _last_ (not first) of a series of improvement to the same type of attacks that were presented in public to much fanfare and promptly followed by public campaigning in favor of DNSSEC...

    I really do not understand the need for such secrecy. Should I assume that CVS commits are censored too? or that *all* "bad guys" are too dumb to infer the problem from the solution? If the apparent "solution" to the problem is to randomize the source port of all queries in order to add 16bits of entropy (in the absolute best case scenario) then I'll say that's just one of many ways to address the problem and perhaps not even the best one.

    oh.. yeah.. DNSSEC is that list too and *NO* it is not the better way to solve this.


    oops, i said DNSSEC twice, Ptacek will go wild!
    • ^
    • v
    I think you agree with me on DNSSEC, and, for the record, when you and I disagree about something, Ivan, I think twice before going wild about it.
    • ^
    • v
    Speaking of DNSSEC, would either Thomas or Dan like to comment on ISC's assertion that "DNSSEC is the only definitive solution for this issue"?

    (Source: http://www.isc.org/index.pl?/sw/bind/bind-secur...)
    • ^
    • v
    It's asinine. If a whole new protocol is needed to solve this problem, let's just make the DNS XID 64 bits, instead of deploying a new PKI that is uncertain to work.

    The ISC people said this "last time", in 1996 --- "we'd randomize source ports, but that won't fix the problem completely, and the real solution is DNSSEC. Let's do that!" The problem? The DNSSEC they were talking about then got SCRAPPED and rebuilt, because it was designed in ways that made it impossible to deploy.
    • ^
    • v
    Just a quick note, I've praised DJB in every single press event I've done -- "DJB is incredible, he patched a bug he didn't even know existed", it's on the Black Hat PR call and its been on everything since. The only one I forgot was the original podcast with Rich.

    We've all been misquoted, or underquoted. Goes with the territory :(
    • ^
    • v
    Tom: Blitz? IOActive has put out a press release, but I had to go look for it. I'm sure it's the news sources I read, but I've seen Matasano quoted slightly more than Dan, so far.

    As he says, he thinks it's important to keep the details quite, but to encourage people to patch.

    And he didn't ask you not to look, he asked you not to tell. To whatever degree those are separate.

    Like I said, he's probably obliged to ask. Knowing it will be ignored.
    • ^
    • v
    we don't new a whole new protocol, we can "overload" the current protocol... why not? the RRs have been abused for hundreds of less relevant purposes
    • ^
    • v
    Ryan: You're not going to win that argument. We're not in the Trib, or at the BBC. People we talk to all the time get wind of a shitstorm about DNS, and ask what I think. We didn't reach out.

    I've got a bit of experience dealing with stories like these, and I don't think you hit the mainstream press by sitting back and doing nothing to promote your work.
    • ^
    • v
    Tom: You misunderstand what I'm calling noise. The BBC is not noise. The security community setting up straw men on Kaminsky's behalf and then accusing him of media whoring is noise. Go read fulldisclosure today.

    The tactic is to claim this is old stuff and attack Dan for not doing interesting work while he can't say anything. Expectations will be raised so high by the time his presentation happens that he can't possibly meet them, and those who attacked him will claim victory.

    See also: Trying to present on wireless driver vulnerabilities or embedded architectures where a null pointer overwrite is useful.
    • ^
    • v
    You (we; security guys) hit the mainstream press by some combination of: finding a flaw that causes large coordinated release, putting out a press release, and having enough bloggers talk about you.

    Dan is guilty of finding the flaw, "allowing" IOActive to put out a press release, and doing a couple of podcasts for technical blogs. And later, providing quotes for a couple of mainstream news outlets. I don't think he even wrote his own blog entry until a decent way into the process. I've done all the same before, I'm just rarely as successful at it.

    Which of those steps would you have put a stop to, Tom?
    • ^
    • v
    since when doing research on "old stuff" is intrinsically bad or diminishes somebody's work?
    In any case, all at Matasano should be happy now.. this randomized UDP source port thingie of will make firewall rules and logfiles such a fun thing to play with. I wonder if they had this in their playbook all along and just planted the idea in Dan's brain exactly at the right time to have it blossom now. That Rauch character probably did it, he posts only when strange things happen in the internec
    • ^
    • v
    Ryan: This story has a formula:

    vague disclosure + talking to the media + announcing that all we be made clear in the future (and the future tends to correspond to a talk at a security conference) = this situation.

    I think researchers tend to get trapped by disclosing just enough information that when the mainstream press hears it, they make it sound like the world is going to end. Security folks are left with a lot of questions. I've had a couple of customers call me and ask how concerned they should be and they have their boss asking them if they are safe.

    If the issue is fixed and the world knows how to fix it, what's changing between now and Black Hat that is impacts when the world can know about it? Is this about waiting for people to patch? Is there another patch coming?
    • ^
    • v
    One variation from the formula in this case (to Dan's advantage) is that initial vague disclosure began with a patch. We won't be having any vendor denial this time, thankfully.

    The uninformed speculation is around why Dan won't disclose details. His stated reason is that he wants people to have more time to patch before the attacks start.

    I believe Black Hat requires one to hold the good stuff for one's talk, yes?

    I would be completely unsurprised if at least one of the coordinated vendors or Vixie or CERT requested that Dan hold details until his talk. Or perhaps Dan gave a drop-dead date of his talk, and someone is holding him to that.

    Dan has zero control over others figuring out his attack and releasing details. Even when they do, he probably still can't say anything until his talk. The only possible schedule change Dan could have made here was to release details before someone else, right?

    So are you and Tom saying that what you guys would be doing differently is that you would have shipped the exploit by now?

    FWIW, Dan seems to me to not be a fan of blindsiding vendors. In a couple of the books I've done with Dan in the past, he was none too thrilled about people printing 0-day.
    • ^
    • v
    Ryan: It is a good question as to what we would do differently. To date, we have avoided the situation. Maybe its been luck. I know readers will have a hard time believing this, but I have, on several occasions, wound down talking to the press because I saw some of our findings getting misrepresented or blown out of proportion.
    • ^
    • v
    It's also the case that we basically do two kinds of work here: broadly theoretic stuff, like tools development or studies of protocols and types of products, and very specific work done under NDA for clients.

    And it's also the case that a couple times we've hit the press on specific stuff we were at liberty to disclose, we got rolled a bit too.
    • ^
    • v
    *yawn*

    In other news, leaving a shiny new BMW in a ghetto with keys inside and doors unlocked will lead to it being stolen.
    • ^
    • v
    @Evil: And what exactly is the 'shiny BMW' in this case?

    While leaving an expensive car in a high-crime area is just a bad idea, running DNS is a necessity. You can consider it a "necessary evil", but the Internet would not function without it. So the best you can do is secure it as much as possible and hope for the best. Using products from security-conscious coders (i.e DJB) is a good start, but that's still not removing the 'shiny car' from the bad neighbor that is the Internet. The best you can is to put The Club on it, maybe an alarm, take the keys out and hope that 'bad guys' will target low-hanging fruit instead. (Does this analogy still make sense? Probably not, it's late.)
    • ^
    • v
    Leaving a shiny new BMW in a San Francisco tow zone will also lead to it being stolen, for the record.
    • ^
    • v
    Man, you people and your car analogies.

    So the XID is like the fuel injection system, and the UDP port selection is like a non-synchronized transmission...
    • ^
    • v
    Ok, ok, I'm trying to picture this.

    5 years after a vulnerability was first described publicly by DJB, Dan Kaminsky, a mediocre security consultant from a dark corner of the interweb, for no reason whatsoever manages to suddenly pull a number of important security vendors together on Microsoft Campus in march 2008. You have to at least admire this man's social engineering skills: no-one, not even DJB himself, nor a single one of all the smart guys posting comments on this page, has managed to convince just one of these vendors to fix this critical vulnerability in 5 years.

    Back at Microsoft Campus, the mission of this gathering of high-profile IT professionals is laid out: to take a couple of days out of their busy schedules to reinvent a solution which already has been freely available to the public for 5 years. How about that. I heard Microsoft is also releasing a new version of their IP stack, referred to internally as 'the Kaminsky stack', which by design will route packets as inefficiently as possible - one day Ballmer simply told his boys to "make a stack that makes packets takes as many hops as humanly possible".

    Anyway, after these bright developers from such previously respected companies as Cisco, Microsoft and the ISC - along with no-one less than Paul Vixie - adjourns from the 5-year-old-patch-reinvention-exercise and retreats to their usual high-paid day jobs, aforementioned Kaminsky steps up and fools everyone in security media into thinking that he has discovered a new, critical vulnerability in DNS. The story makes it across the globe and yet not a single one of the involved vendors, nor Paul Vixie, nor the CERT bothers challenging Kaminsky's public claims. They are all to busy working out the new least-efficient-routing-algorithm for Microsoft. That's what CERT is for anyway, right - to induce unwarranted panic and release information that is biased to boost some dude's personal PR-stunt. Yeah, its right there at the bottom of the security advisory they sent out to all those companies and organizations all over the world.

    You were right guys, it's all so clear to me now: this Dan fellow is one heck of a smooth operator - and I can't wait to see him go down in flames at his talk in august. I bet he can't either - I mean, why stage something like this if you don't like to be the ridicule of the entire industry you work within for years to come. Surely, it must be some kind of humiliation fetish of he is betting his job on.

    See you all at Black Hat in a month - and don't bother with those patches, its all bull anyway.
    • ^
    • v
    Anders: you're wrong this time.
    • ^
    • v
    People running BIND on RedHat and similar systems need to be very careful.

    http://rhn.redhat.com/errata/RHSA-2008-0533.html

    only tells part of the story.

    RedHat's original and updated bind and caching-nameserver packages come with .conf files which specify

    query-source port 53;
    query-source-v6 port 53;

    Users will need to comment that out and restart named to make BIND use random source ports when forwarding requests.
    • ^
    • v
    Dan has made a living of wh0ring out his mediocre findings. This is no different, and I very much look forward to seeing his BH talk and the resulting "oomf". Shades of the RST attack and how the intranets are going down. Oh noes! The world is coming to an end. I can insert shell code on IOS, wait a minute!, this was already postulated, yet we are still to see evidence of it. Yet again, another example of "yes it is possible, but it is not practial". Disclaimer: I am six beers under the belt right now. Dan Kaminsky is a smart mofo, I just don't understand the hype, nor will I ever.
    • ^
    • v
    GG you got PWNED and you started it. Walking into a gunfight with a knife is the analogy I suppose.
    • ^
    • v
    Some of the postings here above show that no matter how a researcher announces his work there's always a segment of the population that ridicules them.

    Let's just wait to see how things play out after the details are released.
    • ^
    • v
    Tom:
    If my 450 word attempt at sarcasm did not get through to you, shame on me. If you still think Dan has nothing, shame on you (reading your latest post, though, I know that's not the case).

    I was merely addressing all the people calling 'media whore' on Dan on this page. To be clear: It is obvious from the circumstances that Dan has something of at least peripheral importance. Everyone has to stop pretending they have known about this vulnerability since 2003 and wait just 4 weeks for the full disclosure.
    • ^
    • v
    There seems to be an unspoken assumption that only one upstream is spoofed. I wonder if there is a negative spoof, first.
    • ^
    • v
    When: Wednesday, August 6, 7:30 PM – 9:30 PM
    Where: Blackhat/Shadow Bar, Caesar's Palace, Las Vegas
    What: Discuss over a drink ;)
    • ^
    • v
    Tom,

    I'm amazed reading through this blog as to how much you bash Kaminsky...prior to "accidently" publishing the exploit after it's disclosed to you. tell us, how does a security company accidently disclose such a serious vulnerability? all i see is a bruised ego looking to one up a fellow researcher.

    and you guys pride yourself as being an infosec company?

    lame...very very lame.

Trackbacks

close Reblog this comment
Powered by Disqus · Learn more
blog comments powered by Disqus