lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 13 Jul 2008 16:27:48 -0500
From: "eugaaa@...il.com" <eugaaa@...il.com>
To: "Paul Schmehl" <pschmehl_lists_nada@...rr.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: DNS Cache Dan Kamikaze (Actual Exploit
	Discussion)

Hi Paul,

I think maybe you misinterpreted.

If the patch is there, and it is (ar x leads you right to
libisccfg.so.1 - the shared lib used by bind that has been patched)
then obviously there isn't a need to wait for Dan.

So on that note I'll be more direct. Has anyone actually preemptively
written any code or reversed this issue on their own? Or just, you
know, attempted to understand the vulnerability in detail instead of
relying on these intentionally vague advisories (dan)?

(PS - Why would I ask you if a patch fixes a vulnerability? It's a
security mailing list...)

On 7/13/08, Paul Schmehl <pschmehl_lists@...rr.com> wrote:
> --On July 13, 2008 2:50:26 PM -0500 eugaaa@...il.com wrote:
>
>> http://blogs.zdnet.com/security/?p=1466
>> Can someone clarify what they meant by "non-reversible patch" ?
>>
>
> The patch changes the default behavior of dns so that queries are
> responded to from random ports rather than always from the same port
> (usually 53.)  Reversing the patch merely returns you to the previous
> default behavior.  It does not get you to the vulnerability that, in
> conjunction with non-random port responses, would allow you to spoof dns
> queries.  (This is speculation on my part.  Dan hasn't shared the details
> me with.)  IOW, there is a separate vulnerability in dns, which Dan has
> not yet revealed, that allows you to take advantage of the non-random
> nature of query responses.
>
> Readers should note that if you override the patch behavior by specifying
> a query response port (the syntax is available to do that), you negate the
> patch.
>
>> http://www.debian.org/security/2008/dsa-1603
>> Are these .deb patches automagical?
>>
>
> If you mean, is bind patched after you've followed the directions in the
> advisory (i.e. run apt-get update and then apt-get install bind9), then
> yes, it "automagical" as you put it.
>
>> *scratches head*
>> I'm not interested in discussing the hype or scene-war aspect of this
>> vulnerability.
>>
>> Has anyone actually verified the impact of this vulnerability? Any code,
>> anything?
>> (http://www.milw0rm.com/exploits/4266)
>>
> No because the real vulnerability has not yet been released.  (Again, this
> is my speculation.)  The patches will make bind much more resistant to a
> spoofing attack that would have been easy to do once the real
> vulnerability is revealed publicly.
>
> BTW, if you want to check your name server (so long as it's not doing
> forwarding), you can run this command:
> # dig @yourserver +short porttest.dns-oarc.net TXT
>
> A patched server will respond like this:
> # dig @ns1.stovebolt.com +short porttest.dns-oarc.net TXT
> z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
> "66.221.101.249 is GOOD: 26 queries in 1.3 seconds from 26 ports with std
> dev 18347.40"
>
> An unpatched server will return POOR: 26 queries in 1.3.seconds from 1
> port.
>
> Paul Schmehl
> If it isn't already obvious,
> my opinions are my own and not
> those of my employer.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ