David Woolley <david@ex.djwhome.demon.invalid> wrote: > Paranoia? Security alerts are generally not that explicit (and this one > is actually unusually explicit) because they provide information to the > hackers.
That is usually obtained anyway be reverse-engineering the fix. In this case that is more difficult because an entire new release was pushed out as a fix. > There are only two places where crypto_recv is called. One is > definitely only active if autokey has been explicitly configured. The > other is only active for broadcast clients and the comments imply that > it is only used for autokey, but it does seem possible that it is the > remote side that decides this (I didn't follow the code any deeper); it > is in the initial broadcast client handshake. Ok that should make servers on internet less vulnerable. Maybe an attack can be done on a local network but I am not worried about that. > I'm using 4.2.7p333, rather than the latest 4.2.7 source code. Most interesting is of course the situation in 4.2.6p5 In 4.2.7 there are already changes that may have partly fixed this. > "Carefully crafted" in alerts generally means that the data has to look > like the address of some instructions and those instructions, with the > exact memory layout under which that instance is running. It also > normally assumes that the machine doesn't have stack execution > permission disabled for ntpd. Of course I run ntpd as a dedicated user ntp and in a chroot. That should also limit the impact. This is default on OpenSUSE. I think in Debian the separate user is default but the chroot isn't. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions