[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190513123254.GF22349@unicorn.suse.cz>
Date: Mon, 13 May 2019 14:32:54 +0200
From: Michal Kubecek <mkubecek@...e.cz>
To: netdev@...r.kernel.org
Cc: Weilong Chen <chenweilong@...wei.com>, davem@...emloft.net,
kuznet@....inr.ac.ru, yoshfuji@...ux-ipv6.org
Subject: Re: [PATCH net-next] ipv4: Add support to disable icmp timestamp
On Mon, May 13, 2019 at 08:26:18PM +0800, Weilong Chen wrote:
> On 2019/5/13 20:11, Michal Kubecek wrote:
> > On Mon, May 13, 2019 at 08:06:37PM +0800, Weilong Chen wrote:
> > > On 2019/5/13 19:49, Michal Kubecek wrote:
> > > > One idea is that there may be applications using current time as a seed
> > > > for random number generator - but then such application is the real
> > > > problem, not having correct time.
> > > >
> > > Yes, the target computer responded to an ICMP timestamp request. By
> > > accurately determining the target's clock state, an attacker can more
> > > effectively attack certain time-based pseudorandom number generators (PRNGs)
> > > and the authentication systems that rely on them.
> > >
> > > So, the 'time' may become sensitive information. The OS should not leak it
> > > out.
> >
> > So you are effectively saying that having correct time is a security
> > vulnerability?
>
> No, I mean that a server should not provide time to others if not necessary.
If the system time is in sync, the attacker knows host's system time
even without ICMP timestamp messages. So if leaking system time via ICMP
timestamp replies is considered a security issue, so must be running
with properly synced system time.
> > I'm sorry but I cannot agree with that. Seeding PRNG with current time
> > is known to be a bad practice and if some application does it, the
> > solution is to fix the application, not obfuscating system time.
> >
> As I said, users can use Firewall to achieve the purpose. This patch just
> provide a simple way.
>
> I can resubmit this patch and set default to 1, preserving current behaviour
> by default. Does that OK for you?
I would be less opposed to such version but I'm still not convinced we
do need another sysctl for this. But it's not up to me to decide, it's
just my opinion.
Michal Kubecek
Powered by blists - more mailing lists