Netdev List
 help / color / mirror / Atom feed
From: John Haxby <john.haxby@gmail.com>
To: Ido Schimmel <idosch@nvidia.com>
Cc: John Haxby <jch@thehaxbys.co.uk>,
	dsahern@kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH 1/1] net/ipv4: discard icmp timestamp requests
Date: Thu, 23 Jul 2026 17:37:50 +0100	[thread overview]
Message-ID: <B4BAD3B3-D795-4863-B20A-F457BE24CB77@gmail.com> (raw)
In-Reply-To: <20260723090858.GA3224213@shredder>

[-- Attachment #1: Type: text/plain, Size: 2285 bytes --]



> On 23 Jul 2026, at 10:08, Ido Schimmel <idosch@nvidia.com> wrote:
> 
> On Wed, Jul 22, 2026 at 11:24:41AM +0100, jch@thehaxbys.co.uk wrote:
>> An icmp timestamp request is classed a a minor security vulnerability
>> (CVE-1999-0524) due to an information leak.  As pretty much everything
>> uses NTP these days, it's not as though this is an actual problem but
>> scanners flag this so for everyone's sake, let's just discard timestamp
>> requests.
> 
> The idea was discussed in the past and was rejected:
> 
> https://lore.kernel.org/netdev/1557711193-7284-1-git-send-email-chenweilong@huawei.com/
> https://lore.kernel.org/netdev/1557754137-100816-1-git-send-email-chenweilong@huawei.com/
> https://lore.kernel.org/netdev/20240520165335899feIJEvG6iuT4f7FBU6ctk@zte.com.cn/
> 
> I don't see a reason to revisit this.

In fact, there is a reason to revisit this.  CVE-1999-0524 went from having a CVSS score of 0.0 (ie not a vulnerability) to CVSS2 score 2.1 in 2022 and today it has a CVSS3.x score of 4.0.   Those first two links are messages in 2019, well before there was a non-zero score.  The last link is, admittedly, 2024 but rather than completely removing ICMP timestamp (as was done with ICMP address, the other part of CVE-1999-0524) is provides a sysctl to turn it off.   I wasn't aware of that possible patch, but it assumes that there's a use-case for ICMP timestamp and in the few years I've been aware of this as an issue (in my previous job) I haven't found one.

Admittedly, it's easy to just disable the timestamp in a firewall (eg firewall-cmd --add-icmp-block=timestamp-request) but people have to discover that after a scanner has screamed warnings about unfixed vulnerabilities.  So now I have actual time on my hands not dealing with the daily firefight of kernel CVEs, I had time to actually do something about this that's been annoying me and quite a lot of other people -- I mentioned googling for "CVE-1999-0524 fix".

If there's a genuine use-case for ICMP timestamp, then yes, it should stay and we'll just add to the documentation from Cisco, f5, Dell, Oracle, etc to explain how to disable it if you don't have that use case.  But lacking a use-case, I still think ICMP timestamp should simply be consigned to the bin.

jch

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

      reply	other threads:[~2026-07-23 16:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-22 10:24 [PATCH 0/1] net/ipv4: discard icmp timestamp requests jch
2026-07-22 10:24 ` [PATCH 1/1] " jch
2026-07-23  9:08   ` Ido Schimmel
2026-07-23 16:37     ` John Haxby [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=B4BAD3B3-D795-4863-B20A-F457BE24CB77@gmail.com \
    --to=john.haxby@gmail.com \
    --cc=dsahern@kernel.org \
    --cc=idosch@nvidia.com \
    --cc=jch@thehaxbys.co.uk \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox