No timeout when reading requests from clients

Bug #882873 reported by Craig Miskell
This bug affects 1 person
Affects Status Importance Assigned to Milestone
apt-cacher (Ubuntu)

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)
ProcVersionSignature: Ubuntu 2.6.35-30.61-generic
Uname: Linux 2.6.35-30-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
Date: Fri Oct 28 14:02:43 2011
 PATH=(custom, user)
SourcePackage: apt-cacher

Revision history for this message
Craig Miskell (3-crjig-7) wrote :
Revision history for this message
Marc Deslauriers (mdeslaur) wrote : Bug is not a security issue

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.

security vulnerability: yes → no
security vulnerability: yes → no
visibility: private → public
visibility: private → public
tags: added: maverick
Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "Patch that mitigates the issue" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-sponsors please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

tags: added: patch
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.