Crashes behind reverse proxy

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Run behind reverse proxy. Tested with with Apache and mod_proxy /w SSL 
enabled on port 443. Shellinabox is NOT using SSL in my tests.
2. Attempt to login via shellinaboxd
3. Crash

What is the expected output? What do you see instead?

I expect the daemon to keep running, or at worst, for a subprocess to die.  In 
2.7, I could use shellinabox behind a reverse proxy. Now, this is broken in 
2.9, 2.10, and the current SVN.  Shellinabox runs successfully when accessed 
directly, although malicious users could - at least - still launch a successful 
(and simple) DoS attack against the service through this vulnerability.

Sometimes the web server will supply the login information and will wait until 
user input before crashing, and other times it will crash immediately upon 
loading the page.

The error I receive from the current SVN r215:
Check failed at libhttp/httpconnection.c:1563 in httpHandleConnection(): offset 
+ pushBack == bytes

What version of the product are you using? On what operating system?

r215 on Debian Lenny.

Please provide any additional information below.

Original issue reported on code.google.com by ewindi...@gmail.com on 27 Aug 2010 at 4:51

[GoogleCodeExporter]

Running shellinabox over SSL (with communication between the proxy and 
shellinabox via SSL), and re-encrypting from the reverse proxy to the end-user 
seems to work successfully.

My recommendation is that all users use shellinabox over SSL, even if run 
behind an additional SSL accelerator/proxy until this is resolved.  Due to the 
performance impact of double-SSL, it may be preferable, if possible in your 
environment, to have shellinabox manage all SSL communications itself.

Original comment by ewindi...@gmail.com on 27 Aug 2010 at 5:45

[GoogleCodeExporter]

Any type of crash is something I am definitely concerned about and consider a 
high priority bug.

Unfortunately, you are not only the first person to report this problem, I am 
also entirely unable to reproduce the problem. This makes it very hard for me 
to debug.

I don't doubt that there is a bug in my code somewhere, but I don't see 
anything obviously wrong with the code. So, it must be something more subtle.

How comfortable are you with C code? Could I ask you to sprinkle some debug 
statements into the code to see where we last modify "offset", "pushBack", and 
"bytes"? And what their values are. That might shed some light on what is 
happening.

If that is too much to ask, could you instead (or in addition) run strace with 
these arguments: "strace -s 4096 -o strace.log shellinaboxd -d ..."

This will be a much harder way to track the bug, but it might still help me 
come up with some theory of what is going on. Please don't enter any valuable 
passwords when doing this. "strace" will end up logging them.

Original comment by zod...@gmail.com on 27 Aug 2010 at 5:54

[GoogleCodeExporter]

I'm comfortable with C, albeit slightly rusty. Given the time, I'm sure I could 
provide a patch... However, I won't have the time for much more investigation 
on this issue for about another week.

Since I don't have a lot of immediate time, I opted to provide output from 
strace.  From this, I found something a bit interesting... it crashes much less 
frequently, hardly at all, when run from strace.  If I run shellinaboxd with 
the same arguments, outside of strace, it crashes almost immediately.  In fact, 
in about 15 minutes of testing with strace, I only managed to crash it a couple 
times.

The attached log represents the "shortest time to crash" which I could muster 
with strace enabled. I can also post a longer session for comparison, if 
desired.

Original comment by ewindi...@gmail.com on 27 Aug 2010 at 6:51

[GoogleCodeExporter]

Thank you very much for the strace log. I was able to reproduce a check() 
failure by replaying parts of your log file. I just checked in a fix for this 
problem. Please verify that it does indeed address the issue when running on 
your system.

The crash was somewhat difficult to reproduce, but I suspect it might be 
related to either HTTP pipelining or to incorrect computation of the 
Content-Length header. Either one could conceivably trigger this check failure.

Original comment by zod...@gmail.com on 27 Aug 2010 at 10:25

• Changed state: Fixed