You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Run "nc 127.0.0.1 50000" in one terminal. Ignore the negotiation/authentication blurb that's printed.
Run "mclient -h 127.0.0.1 -d mydb" in another terminal. Nothing will appear to happen.
Ctrl-C the netcat in the first terminal. The second terminal will unstick itself.
The second terminal will never unstick until nc is Ctrl-Ced.
While this could be considered an exploitable unauthenticated DoS, anybody running a database on an untrusted network is an idiot. I'm creating this bug because I've managed to trip over this on several occasions simply by normal network glitches and/or clients going nuts, and it's inconvenient to have to restart the whole database simply to unstick it.
It looks like this is actually two bugs. One in mserver5 and one in monetdbd.
My first attempt to reproduce worked (in the sense that the bug showed up), but the problem was in monetdbd. It was waiting for a response from nc to continue the authentication process. mserver5 was blissfully unaware of any attempt at connecting.
My second attempt was to connect directly to mserver5, and now it was waiting for an authentication response.
Date: 2015-03-19 16:45:39 +0100
From: Richard Hughes <<richard.monetdb>>
To: Merovingian devs <>
Version: 11.19.9 (Oct2014-SP2)
Last updated: 2015-05-07 12:37:56 +0200
Comment 20725
Date: 2015-03-19 16:45:39 +0100
From: Richard Hughes <<richard.monetdb>>
Build is Oct2014 e58372859532
To reproduce:
Run "nc 127.0.0.1 50000" in one terminal. Ignore the negotiation/authentication blurb that's printed.
Run "mclient -h 127.0.0.1 -d mydb" in another terminal. Nothing will appear to happen.
Ctrl-C the netcat in the first terminal. The second terminal will unstick itself.
The second terminal will never unstick until nc is Ctrl-Ced.
While this could be considered an exploitable unauthenticated DoS, anybody running a database on an untrusted network is an idiot. I'm creating this bug because I've managed to trip over this on several occasions simply by normal network glitches and/or clients going nuts, and it's inconvenient to have to restart the whole database simply to unstick it.
Comment 20729
Date: 2015-03-20 10:21:14 +0100
From: @sjoerdmullender
It looks like this is actually two bugs. One in mserver5 and one in monetdbd.
My first attempt to reproduce worked (in the sense that the bug showed up), but the problem was in monetdbd. It was waiting for a response from nc to continue the authentication process. mserver5 was blissfully unaware of any attempt at connecting.
My second attempt was to connect directly to mserver5, and now it was waiting for an authentication response.
Comment 20730
Date: 2015-03-20 11:13:29 +0100
From: MonetDB Mercurial Repository <>
Changeset 312dc4e64454 made by Sjoerd Mullender sjoerd@acm.org in the MonetDB repo, refers to this bug.
For complete details, see http//devmonetdborg/hg/MonetDB?cmd=changeset;node=312dc4e64454
Changeset description:
Comment 20731
Date: 2015-03-20 13:22:47 +0100
From: MonetDB Mercurial Repository <>
Changeset 8acd025b3ee1 made by Sjoerd Mullender sjoerd@acm.org in the MonetDB repo, refers to this bug.
For complete details, see http//devmonetdborg/hg/MonetDB?cmd=changeset;node=8acd025b3ee1
Changeset description:
Comment 20752
Date: 2015-03-31 11:35:01 +0200
From: @sjoerdmullender
Since I could reproduce the problem before my fixes and I can't after, I'm assuming this is indeed fixed.
The text was updated successfully, but these errors were encountered: