On Sun, Oct 3, 2010 at 00:52, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Alan DeKok" <aland@freeradius.org> writes:
>> CheckRADIUSAuth() in src/backend/libpq/auth.c is subject to spoofing att=
acks
>> which can force all RADIUS authentications to fail.
>> ...
>> The source IP/port/RADIUS ID && authentication vector fields are checked
>> *after* the socket is closed. =A0This allows an attacker to "race" the R=
ADIUS
>> server, and spoof the response, forcing PostgreSQL to treat the
>> authentication as failed.
>
> [ scratches head ... ] =A0I don't see the problem. =A0AFAICS the "verify
> packet" code is just looking at local storage. =A0Where is the spoofing
> possibility, and why would delaying the socket close accomplish
> anything?
I think he's referring to the ability to flood the postgresql server
with radius packets with spoofed IP source, correct? If we then looped
until we got one that validated as a proper packet, we'd still be able
to authenticate with that one, just throwing the invalid ones away.
Notice how the "read packet" part is moved inside the loop in his
suggestion.
--=20
=A0Magnus Hagander
=A0Me: http://www.hagander.net/
=A0Work: http://www.redpill-linpro.com/
