Bug 186057
| Summary: | CVE-2006-1242 Linux zero IP ID vulnerability? | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | Marcel Holtmann <holtmann> |
| Component: | kernel | Assignee: | Thomas Graf <tgraf> |
| Status: | CLOSED ERRATA | QA Contact: | Brian Brock <bbrock> |
| Severity: | low | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4.0 | CC: | davem, jbaron, rkhan, security-response-team |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | impact=low,source=bugtraq,reported=20060314,public=20060314 | ||
| Fixed In Version: | RHSA-2006-0575 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-08-10 22:50:06 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: | |||
| Bug Depends On: | |||
| Bug Blocks: | 181409 | ||
|
Description
Marcel Holtmann
2006-03-21 13:10:06 UTC
The code paths for sending TCP packets when we have a socket and when we don't have one are different, and in fact this is unavoidable. When we send a reset because we don't have a TCP socket that matches, we have to use tcp_v4_send_reset(), which uses the ip_send_reply() framework using the system-wide "tcp_socket" that is used for sending packets when we have no associated socket. SYN+ACK responses, go through yet another interface, ip_build_and_send_pkt() via tcp_v4_send_synack(). We could pass a flag into ip_build_and_send_pkt() to tell it to not use a non-zero IP ID when the DF bit is set. Actually, scratch that, it should be using the function "ip_select_ident_more()" just like ip_build_xmit() does. That would solve the problem. FWIW I don't see this as much of a real security problem, and by fixing it we'll make Linux versions even more specifically identifyable remotely :) According to Chris Wright the latest vanilla kernel contains a fix for it: http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1a55d57b107c3e06935763905dc0fb235214569d Right, I pushed that to 2.6.17 and 2.6.x -stable. Vanilla 2.4.x does not have the problem, but our RHEL3 2.4.x does because it contains the IPSEC backport. RHEL4 is not vulnerable to this with the default firewall enabled, at least not the case documented. Naturally we should include the fix for cases where it is disabled. committed in stream U4 build 34.14. A test kernel with this patch is available from http://people.redhat.com/~jbaron/rhel4/ This issue is on Red Hat Engineering's list of planned work items for the upcoming Red Hat Enterprise Linux 4.4 release. Engineering resources have been assigned and barring unforeseen circumstances, Red Hat intends to include this item in the 4.4 release. Patch is in -42.EL. An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2006-0575.html |