> > 2. who does recursive queries on external interfaces?
> > i would have considerd this a configuration error and
> > security problem ten years ago.
> >
>
> Tell that to the rest of the internet.
without reasonable configuration, most any machine can
be made trivially vulnerable.
> vectors
i don't understand this
1. plan 9 never used a static source port for queries,
and more importantly
Erm, sequential source ports are close enough.
2. who does recursive queries on external interfaces?
i would have considerd this a configuration error and
security problem ten years ago.
T
// 1. plan 9 never used a static source port for queries,
Using dynamic ports is better than static, but if they're
sequential (or otherwise predictable), it doesn't buy you
all that much.
// 2. who does recursive queries on external interfaces?
I've been traveling in companies and countries w
> The exploit doesn't simply rely on the 16bit dns XID.
> Rather, it's reliant on the fact that bind servers
> (and some others) send requests from a static port.
> Obviously, if you control a DNS server or you can
> sniff the target DNS server's path, you can figure
> this out.
>
> The second par
if you're running ndb/dns -r, you need to build and boot a
new kernel to get the full 30 bits.
Bing!
The exploit doesn't simply rely on the 16bit dns XID.
Rather, it's reliant on the fact that bind servers
(and some others) send requests from a static port.
Obviously, if you control a DNS server or you can
sniff the target DNS server's path, you can figure
this out.
The second part to the trick
> And here's snoopy when I run "srv il!192.168.0.108 pinky /n/pinky"
>
> 005784 ms
> ether(s=0002b3079b14 d=003048119871 pr=0800 ln=60)
> ip(s=192.168.0.109 d=192.168.0.108 id=6d28 frag= ttl=255 pr=40
> ln=38)
> il(s=36357 d=9 t=Sync id=31422 ack=0 spec=0 ck=f720 ln=18)
th
>> those things combined mean that you get 15 bits of randomness
>> from query id and 15 from source port, giving 30 bits,
>> so ndb/dns is okay (for now).
>
> why only 15 in the query id? that's an artifact of rand()
> which returns 0 ≤ n ≤ 0x7fff. why not return numbers
> between 0 and 0x?
> those things combined mean that you get 15 bits of randomness
> from query id and 15 from source port, giving 30 bits,
> so ndb/dns is okay (for now).
why only 15 in the query id? that's an artifact of rand()
which returns 0 ≤ n ≤ 0x7fff. why not return numbers
between 0 and 0x?
- erik
>> i'm not a dns user (just the client side) on Plan9,
>> is the server part vulnerable to the recent poisonning attacks?
>
> i think the recent dns cache-poisoning vulnerability
> is more self promotion than substance.
i agreed until i saw the supposed exploit details that were
published last
On Jul 27, 2008, at 10:55 AM, Skip Tavakkolian wrote:
to recap, you can mount the fs from a pccpuf - with the root coming
from a local fs, i assume - but can't boot with the root coming from
fs.
Nope, I cannot mount the fs from my CPU server with a local root.
And, perhaps I should change th
> Any thoughts (other than "man you really botched this
> installation!") :-)
to recap, you can mount the fs from a pccpuf - with the root coming
from a local fs, i assume - but can't boot with the root coming from
fs.
is the domain/hostowner/key combo for fs the same as auth/cpu (values
in nv
> brain# aux/9pcon -n il!192.168.0.108!9fs
> aux/9pcon: dial: connection rejected
does /net/il exist? you may want to check with snoopy
to make sure packets are making it out, too.
cs and a few other programs have had il-ectomies.
> The reason I'm boring you with that information, and the part I
On Jul 26, 2008, at 3:10 PM, Russ Cox wrote:
You can test connectivity using aux/9pcon:
cpu% aux/9pcon -n tcp!web.mit.edu!9fs
aux/9pcon: dial: connection refused
cpu%
If it does connect (which I doubt)
Correct.
brain# aux/9pcon -n il!192.168.0.108!9fs
aux/9pcon: d
> i'm not a dns user (just the client side) on Plan9, is the server part
> vulnerable to the recent poisonning attacks?
i think the recent dns cache-poisoning vulnerability
is more self promotion than substance. my friends
at [dns operator] agree.
however, ndb/dns does use randomized query ids.
could you please clear out how this should work?
I have my own compiled kernel, with the following options:
# zcat /proc/config.gz | 9 grep -i '(lguest|virtio)'
CONFIG_LGUEST_GUEST=y
CONFIG_NET_9P_VIRTIO=m
CONFIG_VIRTIO_BLK=m
CONFIG_VIRTIO_NET=m
CONFIG_VIRTIO_CONSOLE=y
CONFIG_LGUEST=m
CONFIG_VIRTIO
16 matches
Mail list logo
