Is Fedora's glibc vulnerable to this?

--
Bojan

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Tue, Jul 8, 2008 at 8:32 PM, Bojan Smojver <bojan@rexursive.com> 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-conference.mp3

for more details.

Jeff

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

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




--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Bojan Smojver <bojan@rexursive.com> 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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

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




--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

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




--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Tom Lane <tgl@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.

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


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

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@InTechnology.com ]
[ - Comments in this message are my own and not ITO opinion/policy - ]

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

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.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Adam Tkac <atkac@redhat.com> 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


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list