Re: BUG #5687: RADIUS Authentication issues

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/

In response to

Responses

Browse pgsql-bugs by date

  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