Attack code exploiting critical bugs in net time sync(NTP) puts servers at risk

[J65nko]

From http://arstechnica.com/security/2014...rvers-at-risk/

Several critical vulnerabilities in the protocol implementation used to synchronize clock settings over the Internet are putting countless servers at risk of remote hijacks until they install a security patch, an advisory issued by the federal government warned.

The remote-code execution bugs reside in versions of the network time protocol prior to 4.2.8, according to an advisory issued Friday by the Industrial Control Systems Cyber Emergency Response Team. In many cases, the vulnerabilities can be exploited remotely by hackers with only a low level of skill.

For a list of affected operating systems or vendors: http://www.kb.cert.org/vuls/id/852879

[jggimi]

OpenBSD systems are not affected.

[ocicat]

Originally Posted by jggimi

OpenBSD systems are not affected.

For readers who don't explore the tech@ thread cited, the OpenBSD project includes their own ntpd(8) daemon (OpenNTP) included in base installations. This is different from David Mills' version which is available at http://www.ntp.org/ (which is correctly down...), & which is available as a package/port as net/ntp.

[Oko]

Originally Posted by jggimi

OpenBSD systems are not affected.

[rocket357]

There was a bit of LOC counting that took place, then Theo dropped this gem. I really appreciate what he had to say and I wish more software vendors took the same approach.

[gpatrick]

Apparently the
openntpd math was bad

There may be a reason for the math, but apparently Theo just ignores it. I've also read the code for pf is messy and pf also isn't smp-friendly.

The mantra of OpenBSD is no remote holes but now that some software has been removed from the base (Sendmail, Apache, then ever so briefly, nginx) that had the functionality needed, one has to get it from ports, so the schtick is no longer valid since third-party apps are installed.

I'm not knocking OpenBSD, I use it, but Theo isn't the uber smart, be all, end all of operating systems and security it seems some of you praise him for.

[thirdm]

Originally Posted by gpatrick

I'm not knocking OpenBSD, I use it, but Theo isn't the uber smart, be all, end all of operating systems and security it seems some of you praise him for.

That's obviously something of a strawman. It is what it is, but it's a pretty funny coincidence that Theo just happened to take on studying bad pseudo random numbers and seeding and seeing how much could be replaced with arc4random in ports a couple weeks ago (see the tech list archives). Plus they really aren't vulnerable to this one. They also really weren't vulnerable to shellshock.

OpenBSD may not have everything anyone might possibly need or do things always exactly the way every user might wish, but I'm sure wishing I had more time (and skill) to try to figure out how to convert old xaa to newer exa in the old nv driver (or better yet port nouveau over) so I could stop using Slackware on this stupid laptop and get back to OpenBSD. Slackware's nice as linux distros go, but I'm sitting here watching these security vulnerabilities hit the news and finding I'm vulnerable to each one while the system I'd prefer to use isn't.

p.s. on pf not being smp friendly you might also have read or heard that the non-smp OpenBSD pf is faster than FreeBSD smp derivation. SMP isn't the answer to all performance problems.

[gpatrick]

you might also have read or heard that the non-smp OpenBSD pf is faster than FreeBSD smp derivation

What you're talking about is here: FreeBSD pf discussion

I'm not going to read each page as I did yesterday, but what you're referring to is in there and there wasn't any data to backup the claim.

I'd say NetBSD's npf is probably the best designed packet filter available today. Mindaugas has thoughts of porting it to FreeBSD and illumos. NetBSD npf documentation

[jggimi]

Originally Posted by gpatrick

.... pf also isn't smp-friendly...

I agree with this. OpenBSD's PF is a component of its network stack, which runs on CPU 0.

[ibara]

Originally Posted by gpatrick

The mantra of OpenBSD is no remote holes but now that some software has been removed from the base (Sendmail, Apache, then ever so briefly, nginx) that had the functionality needed, one has to get it from ports, so the schtick is no longer valid since third-party apps are installed.

Sendmail was replaced with OpenSMTPD which is really nice if you've never tried it. It's missing a few small things here and there but those things are being actively worked on. Sounds like the OpenSMTPD replacement of sendmail is a great example of how OpenBSD ensures that the mantra isn't a shtick by identifying things in its base system that are not quality and replacing them with things that are.

As to the web server, go find a really good BSD licensed web server that isn't a mess. When you don't find one it seems pretty clear that the only option is to write your own. If you really miss the old apache-1.3, it's in ports as www/apache-httpd-openbsd.

Your statement doesn't hold up to a cursory scrutiny.

[rocket357]

Originally Posted by ibara

Sendmail was replaced with OpenSMTPD which is really nice if you've never tried it.

I can +1 this. OpenSMTPD is a great project and has been rock solid for me. I'm excited to see what happens with the in-base httpd as well.

[Carpetsmoker]

Originally Posted by jggimi

OpenBSD systems are not affected.

I believe that it is more correct to say that systems running openntpd are not affected; you can run ntpd on OpenBSD, and openntpd on other BSD systems or Linux.

[comet--berkeley]

I have never understood why ntpd needs to run all the time in the first place.

In the old days before motherboard clocks with batteries, we used to start up a machine, look at our watch, type in the current date and time and that was it.

These days I automate that process. My /etc/rc.local calls an ntp client to query the time from a time server and then quits.

If I really need the time for a server up 24hours a day, then I can run a daily/hourly cron job to call the ntp client.

[Carpetsmoker]

Originally Posted by comet--berkeley

If I really need the time for a server up 24hours a day, then I can run a daily/hourly cron job to call the ntp client.

So let's say your clock runs fast, maybe by 3 seconds every day, and then every day your system does a 3-second time travel.
The problem here is that a lot of software relies on reliable timestamps, for example for caching or determining if event A happened before or after event B.

Making you clock jump is *often* okay, but *may* have serious side-effects.

I once had a serious problem in a cluster of servers that did exactly what you suggested (setup by "the previous guy", not me), because a shared NFS drive was used, the mtimes were sometimes slightly incorrect, and one webserver would serve outdated content...

[jggimi]

There are client/server systems that require timestamps to be closely synchronized. Kerberos comes to mind immediately, I'm sure there are others.

[comet--berkeley]

Originally Posted by Carpetsmoker

So let's say your clock runs fast, maybe by 3 seconds every day, and then every day your system does a 3-second time travel.
The problem here is that a lot of software relies on reliable timestamps, for example for caching or determining if event A happened before or after event B.

Making you clock jump is *often* okay, but *may* have serious side-effects.

I once had a serious problem in a cluster of servers that did exactly what you suggested (setup by "the previous guy", not me), because a shared NFS drive was used, the mtimes were sometimes slightly incorrect, and one webserver would serve outdated content...

When it comes to assumptions about time, I find it safer to assume that another machine keeps different time from my machine, rather than assume that another machine keeps the exact same time.

For critical systems when synchronizing data from one machine to another, I find it better to use transaction logs and/or version/sequence numbers rather than file modification timestamps (mtime).

In the NFS to webserver example, what happens if a file on the NFS system is intentionally reverted back to an older version of the file from a month ago?

Would the Webserver keep the newer un-reverted version of the file?