Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGOka-0006KE-J1 for pgsql-hackers@arkaria.postgresql.org; Thu, 01 Jun 2017 11:58:48 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dGOka-0005Pn-63 for pgsql-hackers@arkaria.postgresql.org; Thu, 01 Jun 2017 11:58:48 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dGOkZ-0005Od-11 for pgsql-hackers@postgresql.org; Thu, 01 Jun 2017 11:58:47 +0000 Received: from mail-lf0-x232.google.com ([2a00:1450:4010:c07::232]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1dGOkV-0007q0-Sq for pgsql-hackers@postgresql.org; Thu, 01 Jun 2017 11:58:45 +0000 Received: by mail-lf0-x232.google.com with SMTP id 99so25060528lfu.1 for ; Thu, 01 Jun 2017 04:58:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=LCfxXWuyoWrxVaKBa4RswUAYglKPudhZ02vbR3jDd7c=; b=jzsFwCEnQnqfvWTQUBrJLim/I2npZOjWMaESH0JEJeHega95Z42dolyzwkC8VgxLSg 0PD5F/186nWeV5qzgEZbhO41D9C9i3qKnOQMATp8fkYbS4jhCBhl8I93DPK/Edw4XJp4 wTTIyrWj2O7n8YLC1zgFSUFd0+xtdpOUapW/p7EO/u54y5EHSOa2L3VyWAaCQ6hoAbOm zYP1PtAPbIXh420VaXm/iqAUlQRQa3ODEqUePBUNEIrQWUKsZr3VTUqiy3yRimXRIOWj 0ATrFraf5fGNlE3vDtWYKCjgdvvUeb69FlXQHGeGBSLcOYhLSddYHvGcc6ve9DkXJgm3 zxkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to; bh=LCfxXWuyoWrxVaKBa4RswUAYglKPudhZ02vbR3jDd7c=; b=QSSc489G4dfGO7THX/NFuL26SoaMMBVeK3f0BLhd2fA9GM/EOuhgncr0cdhGp9AziP C+GjbKHVSgbI4iEPNGX1U2lo6P079Gis070yDUtiwuiDrIs2HJidnZTfJCIROj9DWTza EDY7uTLkE8G4qL2dOYSzx46RgOndJaXXawWm1f5znUseJ2BpmSVPr2YhaauP4eMitAna JiBPkbKxhlttBICWrM1RBPBOdpIjCoeY/cR4/9eQMGLIC4PiEuOLt6FiNL6wq5UZ4AVg UNqL+eqmGYDjHNe8ds7qe7iT6PTFUpGno/C/0bX8vHrTCsphHthHzf1aTveiI4rYVdVX 0jCg== X-Gm-Message-State: AODbwcDcwDRFhZ1EmVlQVn/mrrQMfVfDkN1H4zpPgTqVTCy6u0vkaWX0 7p3ZlyWcCnyARFAk X-Received: by 10.25.196.207 with SMTP id u198mr481539lff.20.1496318320958; Thu, 01 Jun 2017 04:58:40 -0700 (PDT) Received: from [192.168.1.99] (dsl-hkibrasgw1-50df7f-241.dhcp.inet.fi. [80.223.127.241]) by smtp.gmail.com with ESMTPSA id r80sm475908lfr.65.2017.06.01.04.58.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Jun 2017 04:58:39 -0700 (PDT) Subject: Re: Server ignores contents of SASLInitialResponse To: Michael Paquier References: <5e4ac357-077a-470b-4014-9d9e12f833ba@iki.fi> Cc: PostgreSQL mailing lists From: Heikki Linnakangas Message-ID: <6288d80e-a0bf-d4d3-4e12-7b79c77f1771@iki.fi> Date: Thu, 1 Jun 2017 14:58:36 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------A195CA8DBA64C14E1D0BB1AE" X-Pg-Spam-Score: -2.4 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org This is a multi-part message in MIME format. --------------A195CA8DBA64C14E1D0BB1AE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 05/25/2017 06:36 PM, Michael Paquier wrote: > On Thu, May 25, 2017 at 10:52 AM, Michael Paquier > wrote: >> Actually, I don't think that we are completely done here. Using the >> patch of upthread to enforce a failure on SASLInitialResponse, I see >> that connecting without SSL causes the following error: >> psql: FATAL: password authentication failed for user "mpaquier" >> But connecting with SSL returns that: >> psql: duplicate SASL authentication request >> >> I have not looked at that in details yet, but it seems to me that we >> should not take pg_SASL_init() twice in the scram authentication code >> path in libpq for a single attempt. > > Gotcha. This happens because of sslmode=prefer, on which > pqDropConnection is used to clean up the connection state. So it seems > to me that the correct fix is to move the cleanup of sasl_state to > pqDropConnection() instead of closePGconn(). Once I do so the failures > are correct, showing to the user two FATAL errors because of the two > attempts: > psql: FATAL: password authentication failed for user "mpaquier" > FATAL: password authentication failed for user "mpaquier" Hmm, the SASL state cleanup is done pretty much the same way that GSS/SSPI cleanup is. Don't we have a similar problem with GSS? I tested that, and I got an error from glibc, complaining about a double-free: > *** Error in `/home/heikki/pgsql.master/bin/psql': double free or corruption (out): 0x000056157d13be00 *** > ======= Backtrace: ========= > /lib/x86_64-linux-gnu/libc.so.6(+0x70bcb)[0x7f6a460b7bcb] > /lib/x86_64-linux-gnu/libc.so.6(+0x76f96)[0x7f6a460bdf96] > /lib/x86_64-linux-gnu/libc.so.6(+0x7778e)[0x7f6a460be78e] > /home/heikki/pgsql.master/lib/libpq.so.5(+0xa1dc)[0x7f6a46d651dc] > /home/heikki/pgsql.master/lib/libpq.so.5(+0xa4b3)[0x7f6a46d654b3] > /home/heikki/pgsql.master/lib/libpq.so.5(+0xacb9)[0x7f6a46d65cb9] > /home/heikki/pgsql.master/lib/libpq.so.5(PQconnectPoll+0x14e7)[0x7f6a46d6ae81] > /home/heikki/pgsql.master/lib/libpq.so.5(+0xe895)[0x7f6a46d69895] > /home/heikki/pgsql.master/lib/libpq.so.5(PQconnectdbParams+0x4f)[0x7f6a46d675b9] > /home/heikki/pgsql.master/bin/psql(+0x3daa9)[0x56157ccafaa9] > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f6a460672b1] > /home/heikki/pgsql.master/bin/psql(+0x1163a)[0x56157cc8363a] I bisected that; the culprit was commit 61bf96cab0, where I refactored the libpq authentication code in preparation for SCRAM. The logic around that free() was always a bit wonky, but the refactoring made it outright broken. Attached is a patch for that, see commit message for details. (Review of that would be welcome.) So, after fixing that, back to the original question; don't we have a similar "duplicate authentication request" problem with GSS? Yes, turns out that we do, even on stable branches: psql "sslmode=prefer dbname=postgres hostaddr=127.0.0.1 krbsrvname=postgres host=localhost user=krbtestuser" psql: duplicate GSS authentication request To fix, I suppose we can do what you did for SASL in your patch, and move the cleanup of conn->gctx from closePGconn to pgDropConnection. And I presume we need to do the same for the SSPI state too, but I don't have a Windows set up to test that at the moment. - Heikki --------------A195CA8DBA64C14E1D0BB1AE Content-Type: invalid/octet-stream; name="0001-Fix-double-free-bug-in-GSS-authentication.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-Fix-double-free-bug-in-GSS-authentication.patch" From c75b69e777a52520f9688a8926b9d6986c88c8cc Mon Sep 17 00:00:00 2001 From: Heikki Linnakangas Date: Thu, 1 Jun 2017 13:26:06 +0300 Subject: [PATCH 1/1] Fix double-free bug in GSS authentication. The logic to free the buffer after the gss_init_sec_context() call was always a bit wonky. Because gss_init_sec_context() sets the GSS context variable, conn->gctx, we would in fact always attempt to free the buffer. That only works, because previously conn->ginbuf.value was initialized to NULL, and free(NULL) is a no-op. Commit 61bf96cab0 refactored things so that the GSS input token buffer is allocated locally in pg_GSS_continue, and not held in the PGconn object. After that, the now-local ginbuf.value variable isn't initialized when it's not used, so we pass a bogus pointer to free(). To fix, only try to free the input buffer if we allocated it. That was the intention, certainly after the refactoring, and probably even before that. --- src/interfaces/libpq/fe-auth.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/src/interfaces/libpq/fe-auth.c b/src/interfaces/libpq/fe-auth.c index f4397afc64..f30fb04809 100644 --- a/src/interfaces/libpq/fe-auth.c +++ b/src/interfaces/libpq/fe-auth.c @@ -133,6 +133,11 @@ pg_GSS_continue(PGconn *conn, int payloadlen) return STATUS_ERROR; } } + else + { + ginbuf.length = 0; + ginbuf.value = NULL; + } maj_stat = gss_init_sec_context(&min_stat, GSS_C_NO_CREDENTIAL, @@ -142,13 +147,13 @@ pg_GSS_continue(PGconn *conn, int payloadlen) GSS_C_MUTUAL_FLAG, 0, GSS_C_NO_CHANNEL_BINDINGS, - (conn->gctx == GSS_C_NO_CONTEXT) ? GSS_C_NO_BUFFER : &ginbuf, + (ginbuf.value == NULL) ? GSS_C_NO_BUFFER : &ginbuf, NULL, &goutbuf, NULL, NULL); - if (conn->gctx != GSS_C_NO_CONTEXT) + if (ginbuf.value) free(ginbuf.value); if (goutbuf.length != 0) -- 2.11.0 --------------A195CA8DBA64C14E1D0BB1AE Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers --------------A195CA8DBA64C14E1D0BB1AE--