Re: Dishonest Forks? | Was - Re: [Namedroppers-honest] Brian Smith asks: Who is Dean Anderson?

(Apologies if this gets sent multiple times, my mail gateway had a bit of a 
heart attack)

--On Wednesday, March 10, 2010 9:48 PM -0500 Dean Anderson <[email protected]> 
wrote:

>
> A first post. More blackhats coming, I suppose. Sigh.

Eh, no.  More baseless accusations.  In full disclosure I did work at MAPS 
for about a month, didn't work out due to (IMO) personality conflicts with 
the at the time management.  Paul had put as much distance as he could from 
MAPS at the time due to being personally sued by entities in disagreement 
with MAPS policies/listings.  So I've met Paul Vixie, worked at the 950 
Charter building, but couldn't say that I know Paul at all.  Working @ 950 
Charter is why I know about the building layouts over there, I've never 
been in the Bay Rd. (having never worked at/for Nominum).

>
> On Wed, 10 Mar 2010, Michael Loftis wrote:
>
>> Actually, no, they're not.  They are in the same complex/block of
>> buildings  though.  2385 Bay Rd. is just around the corner from 950
>> Charter and is not  at all the same building.  As to why they moved, I'd
>> guess that it had more  to do with needing more space, or better office
>> space.  Nominum's offices  are, however, no longer at either address.
>> They're still in Redwood city  though.
>
> It appears to be the same building on the mapquest Aerial view.  I don't
> believe you, I guess.

The alleyway is in shadow on the Mapquest images, makes it very difficult 
to resolve.  There are actually three buildings there where Mapquest's 
images lower quality makes it look like one huge one. Google's satellite 
view (if you zoom in a bit from default) shows it much more clearly. 
Working your way south on Charter you have 950 Charter, an alleyway with 
trees, then another building whose address escapes me, but I believe it was 
also on Charter, then separating that building and the Bay Rd. building is 
a narrow breezeway. As I said I don't know any of the specifics of 
Nominum's move, but as big as 950 Charter is, at the time, it was mostly 
unfinished warehouse space...course this is something like 8 yrs ago, but 
there again, the move from Charter to Bay by Nominum was that long ago.

> Hoax by Kaminsky and Day.  We've already been though the citations
> recently. Read the archives before you post.

I have actually.  There's been noone but yourself claiming it was a hoax, 
here, or anywhere that I can find, which is why I've asked you to cite any 
sort of reference.  Further, it isn't a hoax.  I've seen BIND and dnscache 
cache's poisoned by this method in the wild.  There are mitigating factors 
and in order to have a chance of success requires a number of things (such 
as no reverse path filters/spoof filters in place on the nefarious 
client/attacker, or between the nefarious client/attacker and the resolver, 
and it helps to have a relatively healthy uplink).  But in the places it's 
possible, it's rather quite trivial to get it to happen.  The trick is that 
you only need one answer to win the race, worse, if you fail a race, you 
just change the A record you're using to push poisoning onto the cache.  So 
you go first try alice.example.com, send a few hundred requests for that, 
while spoofing responses, if (and when) you get a response from the 
resolver to your question and it's not your spoofed response, you move on 
to say bob.example.com, and keep trying.  alice and bob don't even have to 
exist in the target domain for this one.  And only one spoofed packet (of 
easily many many thousands, or perhaps millions if you've a big enough 
uplink pipe towards the resolver) has to match the randomized bits of the 
packet information.

The problem is that when it succeeds, it's big.  You can even get it to 
succeed for a TLD like net. or com. -- imagine, if you will, being able to 
get even a portion of say...Time Warner's resolvers to divert all lookups 
to net. to your systems.


dnscache turns out to be more vulnerable because you can resource starve 
the resolver by saturating the outstanding query queues.  The patches for 
dnscache, as I understand them, do possibly introduce some other (or ease 
some other) forms of attack, but mitigate this attack.  As to research on 
that topic, I'm personally unaware of any.

Further the "Kaminsky-class" attack, as described, is reproducible, and has 
been reproduced.  The patches (for dnscache and others) -- as best I 
understand them, without other measures such as DNSCurve or DNSSEC -- 
neither of which DNSCurve nor DNSSEC I fully understand...and DNSSEC could 
probably be fooled by this attack in the absence of a root signature/trust 
chain) do not remove any of these vulnerabilities, but they mitigate 
them...since the vulnerability is in the DNS protocol itself.

Some implementations were/are easier to spoof to than others.  TCP (as long 
as you only want on way channels) has similar vulnerabilities, thus SYN 
cookies and other tactics to limit the possibility of similar classes of 
man-in-the-middle attacks.


DNS, as currently standardized, certainly does have it's flaws, but I'm 
sure that Paul Mockapetris did his best, and for a fact was working within 
simplicity constraints imposed by machines of the time.  We also today know 
a lot more about the potential pitfalls than was even remotely possible 
then.

DNS' trust model is most definitely flawed, I'd personally say 
fundamentally so.  That doesn't mean it needs to be thrown out.  We 
certainly can do better with modern systems and techniques.