Re: BUG #5687: RADIUS Authentication issues
От | Magnus Hagander |
---|---|
Тема | Re: BUG #5687: RADIUS Authentication issues |
Дата | |
Msg-id | AANLkTimQOsw22PC7_pcPrSxyLL3bHGkhUxC=NstHBBJ_@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #5687: RADIUS Authentication issues (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #5687: RADIUS Authentication issues
Re: BUG #5687: RADIUS Authentication issues |
Список | pgsql-bugs |
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/
В списке pgsql-bugs по дате отправления: