CVE-2008-1447 v. glibc

[Bojan Smojver]

Is Fedora's glibc vulnerable to this?

-- 
Bojan

[Jeffrey Ollie]

On Tue, Jul 8, 2008 at 8:32 PM, Bojan Smojver <bojan(a)rexursive.com&gt; wrote:
>  Is Fedora's glibc vulnerable to this? 
I think that the problem is mostly a server problem, which means BIND
for the Fedora/RedHat world.  I don't know if any of the other DNS
servers in Fedora/RedHat are vulnerable.  Listen to:

https://media.blackhat.com/webinars/blackhat-kaminsky-dns-press-conferenc...

for more details.

Jeff

[Bojan Smojver]

Jeffrey Ollie <jeff <at> ocjtech.us> writes:

>  I think that the problem is mostly a server problem 
According to this:

http://www.kb.cert.org/vuls/id/800113

It is not just a server problem:

"These caching resolvers are the most common target for attackers; however, stub
resolvers are also at risk."

[...]

"As mentioned above, stub resolvers are also vulnerable to these attacks. Stub
resolvers that will issue queries in response to attacker behavior, and may
receive packets from an attacker, should be patched. System administrators
should be alert for patches to client operating systems that implement port
randomization in the stub resolver."

AFAIK, glibc is stub resolver on Fedora, hence the question.

--
Bojan

[Tom Lane]

Bojan Smojver <bojan(a)rexursive.com&gt; writes:
>  AFAIK, glibc is stub resolver on Fedora, hence the question. 
The normal configuration for a stub resolver is that it's only pointed
to locally-controlled caching servers; so long as you've fixed those
servers, you should be safe AFAICS.

If this analysis is not correct, I'd like to be informed by some means
more polite than breaking into my home machines ;-)

			regards, tom lane

[Bojan Smojver]

Tom Lane <tgl <at> redhat.com> writes:

>  The normal configuration for a stub resolver is that it's only
> pointed
>  to locally-controlled caching servers; so long as you've fixed those
>  servers, you should be safe AFAICS. 
I'm not so much worried about my own configuration, but that of a random Fedora
installation, that may be pointing to caching servers that are not locally
controlled (e.g. that of ISP). That CERT VU#800113 talks about patching of stub
resolvers:

"Stub resolvers that will issue queries in response to attacker behavior, and
may receive packets from an attacker, should be patched."

So, it's more a general question about glibc and this CVE.

--
Bojan

[Bojan Smojver]

Bojan Smojver <bojan <at> rexursive.com> writes:

>  So, it's more a general question about glibc and this CVE.
I just got my answer:

http://lwn.net/Articles/289206/

--
Bojan

[Benny Amorsen]

Tom Lane <tgl(a)redhat.com&gt; writes:

>  The normal configuration for a stub resolver is that it's only
> pointed
>  to locally-controlled caching servers; so long as you've fixed those
>  servers, you should be safe AFAICS. 
The attacker sends reply packets with the source-address of the
locally-controlled caching server. Network firewalls and reverse
path-checking can prevent this attack, but you cannot assume that all
machines with Fedora are behind routers and firewalls set up to
prevent the attack.

>  If this analysis is not correct, I'd like to be informed by some
> means
>  more polite than breaking into my home machines ;-) 
Don't worry, I won't tell anyone that your root password is 12345.


/Benny

[Nigel Metheringham]

On 9 Jul 2008, at 10:41, Benny Amorsen wrote:

>  Don't worry, I won't tell anyone that your root password is
> 12345. 
I'm OK - I used rot13 on it...

oh...

	Nigel.

--
[ Nigel Metheringham             Nigel.Metheringham(a)InTechnology.com ]
[ - Comments in this message are my own and not ITO opinion/policy - ]

[Adam Tkac]

On Wed, Jul 09, 2008 at 04:20:54AM +0000, Bojan Smojver wrote:
>  Jeffrey Ollie <jeff <at> ocjtech.us> writes:
>  
>  > I think that the problem is mostly a server problem
>  
>  According to this:
>  
>  http://www.kb.cert.org/vuls/id/800113
>  
>  It is not just a server problem:
>  
>  "These caching resolvers are the most common target for attackers; however, stub
>  resolvers are also at risk."
>  
>  [...]
>  
>  "As mentioned above, stub resolvers are also vulnerable to these attacks. Stub
>  resolvers that will issue queries in response to attacker behavior, and may
>  receive packets from an attacker, should be patched. System administrators
>  should be alert for patches to client operating systems that implement port
>  randomization in the stub resolver."
>  
>  AFAIK, glibc is stub resolver on Fedora, hence the question.
>  
>  --
>  Bojan 
In my opinion endpoint stub resolvers are not so vulnerable. If you want
spoof DNS data to resolver you have to force that resolver to
send query for name that you know - which is often impossible in
glibc's resolver case (AFAIK only happen when attacker opens
connection to some service and that service asks for attacker's
reverse DNS record for example).

Adam

-- 
Adam Tkac, Red Hat, Inc.

[Benny Amorsen]

Adam Tkac <atkac(a)redhat.com&gt; writes:

>  In my opinion endpoint stub resolvers are not so vulnerable. If you
> want
>  spoof DNS data to resolver you have to force that resolver to
>  send query for name that you know 
This part is generally not a problem. I can think of several ways to
achieve that, and I am sure that there are minds more devious than
mine.


/Benny