No timeout when reading requests from clients
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
apt-cacher (Ubuntu) |
New
|
Undecided
|
Unassigned |
Bug Description
Due to the use of a straight sysread in getRequestLine, if the client goes away (e.g. crashes, or a firewall times out a connection, or the client is malicious and has simply started a basic TCP session) the server process will remain indefinitely. When I saw it on one particular server, there were several hundred processes, some weeks old, causing significant problems.
When in this stuck stage, the child processes must be killed with extreme prejudice (SIGTERM does nothing, SIGKILL is required). This might be considered a security problem of the DoS variety, in that a new non-dying process can be created simply by starting a TCP session (3 packets total). I've submitted this as a security issue in the first instance, but I'm not concerned if it's downgraded to a normal issue.
I have a patch for it (attached). It uses IO::Select and can_read with a timeout to disconnect if the client sends nothing for 60 seconds while we're expecting a request. That only really solves the problem of accidental disconnections; it would need rate-limiting of new inbound connections to keep an attacker from simply creating a lot of connections very very quickly. That's beyond my meager skills I'm afraid. Also, this is my first use of IO::Select, so I may have done something dumb. But, in my defense, it's been running for a day on a box here, serving properly and closing bung connections as expected.
Using TCP Keepalive might be another way to solve the issue, although the defaults on linux boxes (2 hours+) are probably a bit high.
ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: apt-cacher (not installed)
ProcVersionSign
Uname: Linux 2.6.35-30-generic x86_64
NonfreeKernelMo
Architecture: amd64
Date: Fri Oct 28 14:02:43 2011
ProcEnviron:
PATH=(custom, user)
LANG=en_NZ.utf8
SHELL=/bin/bash
SourcePackage: apt-cacher
Thanks for taking the time to report this bug and helping to make Ubuntu better. We appreciate the difficulties you are facing, but this appears to be a "regular" (non-security) bug. I have unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy. Please feel free to report any other bugs you may find.