GZlibCompressor over GSocketConnection sends extra bytes on close
Submitted by alb..@..cor.de
Link to original bug (#795985)
Description
Created attachment 371864 test case, containing the C client, the python server, and a pcap with the erroneous tcp packet.
Sending data through a GZlibCompressor (format G_ZLIB_COMPRESSOR_FORMAT_RAW) on top of a GSocketConnection client tcp connection will send an extra tcp packet containing a 0x03 0x00 payload when the connections are finalised. As the remote server does not expect this, it will send a RST tcp packet. In turn, this may trigger warnings in an IDS (like snort).
As example, I attach a client application and a trivial (Python) server. The client sends a command to enable compression, and then the (compressed) command to terminate the connection to the server. This is basically what the IMAP COMPRESS Extension (RFC 4978) does.
When the test application is built with “#define SIM_ERROR 1”, the compressed GOutputStream and the GZlibCompressor are unref'ed before the other components, and the application sends the erroneous extra bytes (see pcap file).
If it is built with “#define SIM_ERROR 0”, i. e. when the compressed GOutputStream and the GZlibCompressor are unref'ed after all other components, the error does not occur.
However, if the connection is TLS encrypted (the typical use case for IMAP), i. e. the “stacking” looks like
GSocketClient +-- GSocketConnection +-- GIOStream obtained from g_tls_client_connection_new() +-- GOutputStream g_converter_output_stream_new(GZlibCompressor)
unref'ing the compressed GOutputStream and the GZlibCompressor after the TLS connection will trigger a
GLib-Net-CRITICAL **: g_tls_output_stream_gnutls_write: assertion 'conn != NULL' failed
So I have the choice to either suppress the erroneous extra packet, at the cost of the GLib-Net-CRITICAL, or to have no warnings from GLib, but the erroneous tcp packet plus the unwanted RST packet.
The bug is reproducible on Ubuntu 16.04 LTS (gio version ) and Debian Stretch (), both 64-bit systems.
Attachment 371864, "test case, containing the C client, the python server, and a pcap with the erroneous tcp packet.":
testcase.zip
Version: 2.50.x