From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alan DeKok <aland(at)freeradius(dot)org>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #5687: RADIUS Authentication issues |
Date: | 2010-10-03 06:30:28 |
Message-ID: | AANLkTimQOsw22PC7_pcPrSxyLL3bHGkhUxC=NstHBBJ_@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Sun, Oct 3, 2010 at 00:52, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Alan DeKok" <aland(at)freeradius(dot)org> writes:
>> CheckRADIUSAuth() in src/backend/libpq/auth.c is subject to spoofing attacks
>> which can force all RADIUS authentications to fail.
>> ...
>> The source IP/port/RADIUS ID && authentication vector fields are checked
>> *after* the socket is closed. This allows an attacker to "race" the RADIUS
>> server, and spoof the response, forcing PostgreSQL to treat the
>> authentication as failed.
>
> [ scratches head ... ] I don't see the problem. AFAICS the "verify
> packet" code is just looking at local storage. Where 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.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Alan T DeKok | 2010-10-03 06:58:46 | Re: BUG #5687: RADIUS Authentication issues |
Previous Message | Alan T DeKok | 2010-10-03 05:17:15 | Re: BUG #5687: RADIUS Authentication issues |