Bug 168376
| Summary: | squid "pipeline_prefetch on" instability | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | Josh Bressers <bressers> |
| Component: | squid | Assignee: | Martin Stransky <stransky> |
| Status: | CLOSED NEXTRELEASE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4.0 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | impact=moderate,reported=20050915,public=20050915,source=squid | ||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-11-15 09:08:23 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Josh Bressers
2005-09-15 14:56:14 UTC
This issue may also affect RHEL2.1 and RHEL3 Martin, Can you take a look at this issue? I'm not sure if it really is a security issue or not. MITRE is holding off on a CVE name until more is known about it. I spent this day with it but I'm not completely sure what's wrong, I'm going to work on it. Any new news on this? I'm going to sort it out today or tomorrow. But it doesn't look like high-priority-mustfix-now bug. Ping on this issue. Do we know if it's a security issue yet? I sent you it via mail, it may have lost... -------- Original Message -------- Subject: Bugzilla Bug 168376 รข squid "pipeline_prefetch on" instability Date: Tue, 27 Sep 2005 12:15:24 +0200 From: Martin Stransky <stransky> To: bressers Hello Josh, I went through squid sources, I made some tests and I think it isn't a security issue. If squid isn't patched, you can connect to squid by telnet and try to bother it. The problem is when you use a proxy command like this: GET http://people.redhat.com/stransky/squid/squid-2.5.STABLE10-2.src.rpm HTTP/1.1 Host: people.redhat.com Keep-Alive: 3000 Proxy-Connection: keep-alive CONNECT c154wm.psisco.com:443 HTTP/1.1 Host: c154wm.psisco.com Proxy-Connection: keep-alive The first one will start downloading file through http connection. But if you have configured squid to prefetch next command (and connection is keep-alive), squid will process next command "CONNECT". And there is the problem - squid routes all data to SSL conection. (SSL conections go always through proxy w/o any change). And data from GET request are still alive and they are mixed with SSL channel. So client gets data from SSL and GET method by single channel. If the GET method is finished (all data have been send to client), squid will get next command from client. But it uses the same channel like SSL, so squid gets data from SSL as a next HTTP request and result is like this line from log: 2005/09/27 10:33:33| parseHttpRequest: Unsupported method 'xxxxxx' But user who wants to confuse squid with bad requests don't have to do that. He can simply send a malformed request to squid directly, there isn't any diference between keep-alive requests and new opened requests. So it's the reason why I think it isn't a security issue. I have to simulate this situation by telnet because web-clients don't use pipelined CONNECT (they always open a new socket for it), so I think it can't appear in regular traffic. Regards, Martin btw. patches are in CVS... I'm going to downgrade this issue to a non security bug. This is not a security issue. I'm not going to fix it in current RHEL3/4. The fix isn't necessary becase we have the "pipelined" options disabled and browsers don't concatenate the CONNECT method with other ones. (You have to use some tool like netcat or telnet) Consig as NEXTRELEASE. (It's fixed in current FC3/4 and devel). |