Bug 1173640 (CVE-2004-1060) - VUL-0: CVE-2004-1060: kernel-source: Multiple TCP/IP and ICMP implementations, when using Path MTU (PMTU) discovery (PMTUD), allow remote attackers to cause a denial of service (network throughput reduction for TCP connections) via forged I
Summary: VUL-0: CVE-2004-1060: kernel-source: Multiple TCP/IP and ICMP implementations...
Status: RESOLVED FIXED
Alias: CVE-2004-1060
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents (show other bugs)
Version: unspecified
Hardware: Other Other
: P3 - Medium : Normal
Target Milestone: ---
Assignee: Security Team bot
QA Contact: Security Team bot
URL: https://smash.suse.de/issue/15735/
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-07-02 15:27 UTC by Marcus Meissner
Modified: 2024-06-07 07:50 UTC (History)
7 users (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Marcus Meissner 2020-07-02 15:27:25 UTC 
CVE-2004-1060

Multiple TCP/IP and ICMP implementations, when using Path MTU (PMTU) discovery
(PMTUD), allow remote attackers to cause a denial of service (network throughput
reduction for TCP connections) via forged ICMP ("Fragmentation Needed and Don't
Fragment was Set") packets with a low next-hop MTU value, aka the "Path MTU
discovery attack."  NOTE: CVE-2004-0790, CVE-2004-0791, and CVE-2004-1060 have
been SPLIT based on different attacks; CVE-2005-0065, CVE-2005-0066,
CVE-2005-0067, and CVE-2005-0068 are related identifiers that are SPLIT based on
the underlying vulnerability.  While CVE normally SPLITs based on vulnerability,
the attack-based identifiers exist due to the variety and number of affected
implementations and solutions that address the attacks instead of the underlying
vulnerabilities.

References:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2004-1060
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1060
http://www.cisco.com/warp/public/707/cisco-sa-20050412-icmp.shtml
Comment 1 Marcus Meissner 2020-07-02 15:36:05 UTC 
again https://www.rfc-editor.org/rfc/rfc5927.txt I think
Comment 2 Takashi Iwai 2020-07-08 11:20:33 UTC 
A series of ancient reports.  Adding Michal K to Cc.
Comment 3 Jiri Bohac 2020-09-10 17:04:07 UTC 
Results of my research so far - no conclusion yet:

The already contains these generic mitigations against spoofed ICMP packets suggested by RFC5927

4.1.  TCP Sequence Number Checking (since at least v2.4.0)
4.2.  Port Randomization (since v2.6.15)

To mitigate this specific attack RFC 5927, section 7.2, suggests using Packetization Layer Path MTU Discovery (PLPMTUD).

The feature is part of the kernel since commit 5d424d5a674f782d0659a3b66d951f412901faee (v2.6.17)
It is controlled by the net.ipv4.tcp_mtu_probing sysctl but we keep this off by default.

I found one request to turn this on in bsc#971797 but that ended up as WONTFIX.

I am not sure if that is really a sufficient mitigation and also whether that's the only effective mitigation. Quickly looking at PMTU discovery code, enabling 
tcp_mtu_probing does not affect the processing of ICMP_FRAG_NEEDED packets. So if it works as a mitigation it probably works by allowing TCP to recover from the forged decreased PMTU.
Comment 4 Borislav Petkov 2020-10-16 10:03:32 UTC 
So what do we do here, does this need to be discussed with the customer on a mail thread instead?