On Sun, Oct 3, 2010 at 00:52, Tom Lane <t...@sss.pgh.pa.us> wrote: > "Alan DeKok" <al...@freeradius.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/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
