The issue lies within the HTTP header parser, namely in its
"fieldbody_crlf" state
(tnt::Messageheader::Parser::state_fieldbody_crlf). If a '\n'
character is received in this state, the now-completed HTTP header is
processed, and since this new '\n' signals the end of the HTTP header
lines, 'true' is returned. However, the underlying header's raw data
(header.rawdata array) is not null-terminated to indicate the end of
header information. Normally this contains null-terminated key and
value strings, with an extra null terminator to indicate that there
are no more key/value string pairs.

Since this extra null terminator is left off, iterating through the
resulting Messageheader object may result in the iteration continuing
past any real parsed headers and into undefined memory (the rawdata
buffer is only cleared #ifdef DEBUG).

Namely, this undefined memory might be from previous HTTP request
processing, namely a previous HttpRequest's header object's rawdata.

So, by sending a crafted HTTP request that uses only a '\n' to signal
the end of the HTTP headers (instead of a full '\r\n' sequence), one
can get "extra" headers seemingly appended to their HTTP request that
came from previous, unrelated HTTP requests. This is obviously a
problem for HTTP headers like Cookie and the various authentication
headers.

To demonstrate this issue with a POC attack, start the "cookie" tntnet demo:
mattd@morphism:~/tntnet-2.2/sdk/demos/cookie$ ../../../framework/runtime/tntnet
tntnet 2.2
2013-12-10 18:01:38.29129 [25519.3071564000] INFO tntnet.listener -
listen ip= port=29035
2013-12-10 18:01:38.29138 [25519.3071564000] INFO tntnet.tntnet -
create 5 worker threads

Then, enter (nc = netcat, which pipes stdin to the specified hostname/port):
mattd@morphism:~$ while true; do echo -ne "GET / HTTP/1.0\r\nA:\r\n\n"
| nc -q 1 localhost 29035 | grep h1 | grep -v World || sleep 0.1; done
| uniq

Then, using a normal web browser, do a few sample runs with the cookie
sample application, setting some cookies and getting your name back,
so as to simulate normal server load. You should see output from the
previous command whenever it "catches" one of the browser's request
cookies. Note that you may need to refresh the page a few times,
submit various names, etc. before any output comes out. This is just
due to the crudeness of this POC, and the effectiveness of the attack
could be easily improved.

The solution that comes to mind is to simply add the missing
null-termination to the previously mentioned state change code.

Also, note that there is a similar, but not security-impacting issue
relating to not-correctly-null-terminated header rawdata buffers. If
parsing the HTTP request fails and a HttpError exception is thrown
(ie. on too large a header), then the rawdata is not null terminated.
This header data is then used in Worker::logRequest when looking up
the request's username, referer and user-agent. Similar to the
previous issue, either previous requests' data will be used, or the
server will iterate off into undefined/unallocated memory.