View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0004084unrealircdpublic2012-02-06 01:102012-12-15 20:38
Reporterseraph Assigned Tosyzop  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionunable to duplicate 
Product Version3.2.9 
Summary0004084: SSL Sockets for Remote Include are not closed properly
DescriptionToday I found a strange thing:
IRCd Server:
netstat -tulpenaW | grep 443
tcp 38 0 x.y.z.162:32811 a.b.c.200:443 CLOSE_WAIT 10003 1471230 4866/ircd
tcp 38 0 x.y.z.162:32810 a.b.c.200:443 CLOSE_WAIT 10003 1471229 4866/ircd
tcp 38 0 x.y.z.162:32806 a.b.c.200:443 CLOSE_WAIT 10003 1471225 4866/ircd
tcp 38 0 x.y.z.162:32814 a.b.c.200:443 CLOSE_WAIT 10003 1471233 4866/ircd
tcp 38 0 x.y.z.162:32809 a.b.c.200:443 CLOSE_WAIT 10003 1471228 4866/ircd
tcp 38 0 x.y.z.162:32808 a.b.c.200:443 CLOSE_WAIT 10003 1471227 4866/ircd
tcp 38 0 x.y.z.162:32807 a.b.c.200:443 CLOSE_WAIT 10003 1471226 4866/ircd
tcp 38 0 x.y.z.162:32817 a.b.c.200:443 CLOSE_WAIT 10003 1471236 4866/ircd
tcp 38 0 x.y.z.162:32816 a.b.c.200:443 CLOSE_WAIT 10003 1471235 4866/ircd
tcp 38 0 x.y.z.162:32818 a.b.c.200:443 CLOSE_WAIT 10003 1471237 4866/ircd
tcp 38 0 x.y.z.162:32812 a.b.c.200:443 CLOSE_WAIT 10003 1471231 4866/ircd
tcp 38 0 x.y.z.162:32813 a.b.c.200:443 CLOSE_WAIT 10003 1471232 4866/ircd
tcp 38 0 x.y.z.162:32815 a.b.c.200:443 CLOSE_WAIT 10003 1471234 4866/ircd

Config Server (also running an IRCd):
netstat -tupen | grep 443
tcp 38 0 a.b.c.200:54338 a.b.c.200:443 CLOSE_WAIT 1000 3328119 5000/ircd
tcp 38 0 a.b.c.200:54339 a.b.c.200:443 CLOSE_WAIT 1000 3328120 5000/ircd
tcp 38 0 a.b.c.200:54334 a.b.c.200:443 CLOSE_WAIT 1000 3328115 5000/ircd
tcp 38 0 a.b.c.200:54337 a.b.c.200:443 CLOSE_WAIT 1000 3328118 5000/ircd
tcp 38 0 a.b.c.200:54336 a.b.c.200:443 CLOSE_WAIT 1000 3328117 5000/ircd
tcp 38 0 a.b.c.200:54333 a.b.c.200:443 CLOSE_WAIT 1000 3328114 5000/ircd
tcp 38 0 a.b.c.200:54342 a.b.c.200:443 CLOSE_WAIT 1000 3328123 5000/ircd
tcp 38 0 a.b.c.200:54345 a.b.c.200:443 CLOSE_WAIT 1000 3328126 5000/ircd
tcp 38 0 a.b.c.200:54341 a.b.c.200:443 CLOSE_WAIT 1000 3328122 5000/ircd
tcp 38 0 a.b.c.200:54335 a.b.c.200:443 CLOSE_WAIT 1000 3328116 5000/ircd
tcp 38 0 a.b.c.200:54344 a.b.c.200:443 CLOSE_WAIT 1000 3328125 5000/ircd
tcp 38 0 a.b.c.200:54340 a.b.c.200:443 CLOSE_WAIT 1000 3328121 5000/ircd
tcp 38 0 a.b.c.200:54343 a.b.c.200:443 CLOSE_WAIT 1000 3328124 5000/ircd
netstat -tulpenaW | grep 84.19.168.162 shows nothing.

Third Server also running IRCd (this time on OpenSuse) has the same:
tcp 38 0 e.f.g.150:49855 a.b.c.200:443 CLOSE_WAIT 1003 26914551 10993/ircd
tcp 38 0 e.f.g.150:49858 a.b.c.200:443 CLOSE_WAIT 1003 26914554 10993/ircd
tcp 38 0 e.f.g.150:49851 a.b.c.200:443 CLOSE_WAIT 1003 26914547 10993/ircd
tcp 38 0 e.f.g.150:49854 a.b.c.200:443 CLOSE_WAIT 1003 26914550 10993/ircd
tcp 38 0 e.f.g.150:49848 a.b.c.200:443 CLOSE_WAIT 1003 26914544 10993/ircd
tcp 38 0 e.f.g.150:49849 a.b.c.200:443 CLOSE_WAIT 1003 26914545 10993/ircd
tcp 38 0 e.f.g.150:49853 a.b.c.200:443 CLOSE_WAIT 1003 26914549 10993/ircd
tcp 38 0 e.f.g.150:49847 a.b.c.200:443 CLOSE_WAIT 1003 26914543 10993/ircd
tcp 38 0 e.f.g.150:49850 a.b.c.200:443 CLOSE_WAIT 1003 26914546 10993/ircd
tcp 38 0 e.f.g.150:49846 a.b.c.200:443 CLOSE_WAIT 1003 26914542 10993/ircd
tcp 38 0 e.f.g.150:49856 a.b.c.200:443 CLOSE_WAIT 1003 26914552 10993/ircd
tcp 38 0 e.f.g.150:49857 a.b.c.200:443 CLOSE_WAIT 1003 26914553 10993/ircd
tcp 38 0 e.f.g.150:49852 a.b.c.200:443 CLOSE_WAIT 1003 26914548 10993/ircd


It seems that the SSL sockets used to get the config files are not closed properly and simply stay pending in the clients socket list.
Steps To ReproduceUse Remote Includes via HTTPs
3rd party modules

Activities

syzop

2012-02-07 21:29

administrator   ~0016903

TODO (by me or anyone else): verify, check with recent curl, verify if this is only with https or with all remote includes, and fix.

syzop

2012-08-17 13:27

administrator   ~0017079

I cannot reproduce this on my own machine.
Latest mercurial version of today, using libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 c-ares/1.7.3 libidn/1.15 libssh2/0.18

What version do you use? (run /VERSION as IRCOp when online)

I'd be eager to figure this out.

I also tested on 3.2.9 (so the real release from a year ago, not a dev version).. no problem either.

I use:
include "https://www.vulnscan.org/tmp/test.conf";

To make sure the ircd (or libcurl) isn't keeping any sockets open I use:
lsof -n -p `cat ircd.pid`
(optionally, |grep 443)

seraph

2012-08-17 13:49

reporter   ~0017086

lsof -n -p `cat ircd.pid`
ircd 2612 ircdbnc 52u IPv4 1412635 0t0 TCP a.b.c.d:37069->a.b.c.d:https (CLOSE_WAIT)
ircd 2612 ircdbnc 53u IPv4 1412636 0t0 TCP a.b.c.d:37070->a.b.c.d:https (CLOSE_WAIT)
ircd 2612 ircdbnc 54u IPv4 1412637 0t0 TCP a.b.c.d:37071->a.b.c.d:https (CLOSE_WAIT)
ircd 2612 ircdbnc 55u IPv4 1412638 0t0 TCP a.b.c.d:37072->a.b.c.d:https (CLOSE_WAIT)
ircd 2612 ircdbnc 56u IPv4 1412639 0t0 TCP a.b.c.d:37073->a.b.c.d:https (CLOSE_WAIT)
ircd 2612 ircdbnc 57u IPv4 1412640 0t0 TCP a.b.c.d:37074->a.b.c.d:https (CLOSE_WAIT)
ircd 2612 ircdbnc 58u IPv4 1412641 0t0 TCP a.b.c.d:37075->a.b.c.d:https (CLOSE_WAIT)
ircd 2612 ircdbnc 59u IPv4 1412642 0t0 TCP a.b.c.d:37076->a.b.c.d:https (CLOSE_WAIT)
ircd 2612 ircdbnc 60u IPv4 1412643 0t0 TCP a.b.c.d:37077->a.b.c.d:https (CLOSE_WAIT)
ircd 2612 ircdbnc 61u IPv4 1412644 0t0 TCP a.b.c.d:37078->a.b.c.d:https (CLOSE_WAIT)
ircd 2612 ircdbnc 62u IPv4 1413983 0t0 TCP a.b.c.d:37079->a.b.c.d:https (CLOSE_WAIT)
ircd 2612 ircdbnc 63u IPv4 1413984 0t0 TCP a.b.c.d:37080->a.b.c.d:https (CLOSE_WAIT)
ircd 2612 ircdbnc 64u IPv4 1413985 0t0 TCP a.b.c.d:37081->a.b.c.d:https (CLOSE_WAIT)

Version output:
OpenSSL 0.9.8o 01 Jun 2010
zlib 1.2.3.4
libcurl/7.21.0 GnuTLS/2.8.6 zlib/1.2.3.4 libidn/1.15

Meanwhile the system has been newly installed completely, still using Debian 6 and .9

syzop

2012-08-17 19:31

administrator   ~0017088

I see. I'm also on Debian 6 by the way.

One notable difference is that your libcurl is compiled with GnuTLS support instead of OpenSSL support.
Perhaps there's a bug in libcurl when it uses GnuTLS?

syzop

2012-09-24 10:21

administrator   ~0017132

I think that's the only suggestion I can make. Try recompiling libcurl to use OpenSSL instead of GnuTLS, and see if that resolves things.

seraph

2012-09-24 11:15

reporter   ~0017134

I´ll try it when I´ve got the time for it and report

nenolod

2012-11-12 18:58

reporter   ~0017231

CLOSE_WAIT state means that the application has released the socket handle (e.g. file descriptor), but the underlying TCP/IP implementation hasn't closed it out yet.

Do you still believe it to be a bug in the ircd?

syzop

2012-12-15 20:38

administrator   ~0017262

I'm closing this one. If anything, it's a curl/gnutls bug :)

Issue History

Date Modified Username Field Change
2012-02-06 01:10 seraph New Issue
2012-02-07 21:29 syzop Note Added: 0016903
2012-02-07 21:29 syzop Status new => acknowledged
2012-02-26 21:32 syzop Severity minor => major
2012-02-26 21:32 syzop Relationship added child of 0003915
2012-08-17 13:27 syzop Note Added: 0017079
2012-08-17 13:27 syzop Status acknowledged => feedback
2012-08-17 13:49 seraph Note Added: 0017086
2012-08-17 19:31 syzop Note Added: 0017088
2012-09-24 10:21 syzop Note Added: 0017132
2012-09-24 11:15 seraph Note Added: 0017134
2012-10-06 11:48 syzop Relationship deleted child of 0003915
2012-11-12 18:58 nenolod Note Added: 0017231
2012-12-15 20:38 syzop Note Added: 0017262
2012-12-15 20:38 syzop Status feedback => closed
2012-12-15 20:38 syzop Assigned To => syzop
2012-12-15 20:38 syzop Resolution open => unable to duplicate