Control: reopen -1 On 1/24/22 13:25, Christoph Anton Mitterer wrote:
On Tue, 2022-01-18 at 21:52 -0600, Richard Laager wrote:Shouldn't -g be removed?First off, note that the stock ntpsec.service has Restart=no, not Restart=yes. So in the malicious/broken server scenario described, ntpd will die, but not restart.
Isn't it still, that if one e.g. reboots and ntpd starts the first time
Yes, -g is only applicable at boot (or first install).
then an attacker could basically set any time?
There are two potential issues: A) the server serves bogus/malicious time B) a MITM messes with the time.The primary protection for A is consensus (see specifically minsane). A single bogus/malicious clock can't do anything.
Of course, in scenario B, the MITM can mess with all of the clocks you're talking to. NTS is the best protection. The older style fixed secret hash-based (e.g. MD5/SHA) authentication is better than nothing.
But yes, without NTS and with -g (both being the defaults in Debian), ultimately a MITM could adjust all of the times you're seeing and set any time, but only once upon boot. Eliminating -g would improve security in this situation. But there are trade-offs.
One could argue here, that most "normal" systems (desktops, servers) have usually rather well working clocks... an so they wouldn't be likely affected by what you describe.
That's true until it isn't: one day your motherboard's battery dies and now your clock is wrong, despite running ntpd.
OTOH, embedded systems are "special" and if someone uses a system with no clock at all, than IMO it's rather his duty to take necessary steps so that it works (e.g. by installing ntpdate).
I'm not sure how installing ntpdate is different from installing ntpsec in that regard.
Let's say I remove -g by default. (Then I can safely set Restart=on-failure by default.) I could address some/all of the trade-offs:
I'd imagine I could script up something to add -g on the first run of ntpd on initial install, to address that case. For example, I could detect the first run scenario as there being no drift file.
I could use hwclock(1) to determine if there is an RTC. If not, add -g. That would make the Raspberry Pi case work out-of-the-box without decreasing security for regular systems.
That still leaves the case of "my RTC battery died". I could probably detect that too, by checking to see if the current time is older than the drift file, and again add -g.
The only problem I see with this is that if I'm adding -g under various circumstances, there's then no way for the administrator to prohibit -g.
Another option would be to remove -g from $NTPD_OPTS if none of those conditions apply. If I'm only removing -g, the admin can still ensure -g is not used by removing it. This creates the opposite problem: there's no way for an admin to add -g if they want it always. (Unless my -g removal only removes one and they set NTPD_OPTS="-g -g" but that seems like a hack.) But, removing options is itself tricky (e.g. NTPD_OPTS="-gN" or NTPD_OPTS="-Ng") and that feels like asking for trouble.
2) Also in /etc/default/ntpsec, per default IGNORE_DHCP is "". Shouldn't that be set to yes, so that per default a malicious DHCP server couldn't add it's own possible rogue servers?Maybe. But ntpsec-ntpdate isn't installed by default and even installing ntpsec doesn't pull it in. If you choose to install that package, you (arguably) are expressing a desire to use its features, and the DHCP integration is a big part of that.I didn't realise that /etc/default/ntpsec's IGNORE_DHCP actually affects only ntpsec-ntpdate (or at least that's how I understand you)... which however has it's own /etc/default file with it's own IGNORE_DHCP??
Yeah, in looking at this more, this is different / more complicated than I remember, and arguably messy.
So both ntpsec and ntpsec-ntpdate have DHCP support, which is enabled by default (IGNORE_DHCP="").
/etc/default/ntpsec's IGNORE_DHCP affects ntpd from ntpsec./etc/default/ntpsec-ntpdate affects ntpdate-debian (note the -debian there) from ntpsec-ntpdate.
It's technically possible to have both installed, but generally one is either using ntpd or ntpdate-debian, not both.
The only documentation for this is README.Debian, which only references /etc/default/ntpsec. In fairness, lots of that file is talking only about ntpd from the ntpsec package, which ntpsec-ntpdate being a bit of a separate thing / an afterthought.
Really, ntpsec-ntpdate should just die and this gets simpler.As far as DHCP goes, though... the DHCP server controls my address and my gateway. It can trivially MITM me. It could serve me DNS that redirects the pool servers somewhere. Or even without DNS being involved, it could simply serve me a gateway IP that forwards all NTP traffic somewhere.
That said, if I'm using NTS in my ntp.conf, that's being defeated by the DHCP integration. That's probably a good reason to disable DHCP integration by default.
-- Richard
OpenPGP_signature
Description: OpenPGP digital signature
