Thursday, September 10, 2009

Open Source Vulnerability Disclosure with FreeBSD

The purpose of this post is not to bash Microsoft, but I am going to point out why I prefer relying on open source platforms, especially for sensitive systems. One of the advantages of the open source model is that anyone can identify and evaluate changes. This is especially true of open source projects like FreeBSD. Let's look at a recent security advisory in ntpd to demonstrate what I mean.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

=============================================================================
FreeBSD-SA-09:11.ntpd Security Advisory
The FreeBSD Project

Topic: ntpd stack-based buffer-overflow vulnerability

Category: contrib
Module: ntpd
Announced: 2009-06-10
Credits: Chris Ries
Affects: All supported versions of FreeBSD.
Corrected: 2009-06-10 10:31:11 UTC (RELENG_7, 7.2-STABLE)
2009-06-10 10:31:11 UTC (RELENG_7_2, 7.2-RELEASE-p1)
2009-06-10 10:31:11 UTC (RELENG_7_1, 7.1-RELEASE-p6)
2009-06-10 10:31:11 UTC (RELENG_6, 6.4-STABLE)
2009-06-10 10:31:11 UTC (RELENG_6_4, 6.4-RELEASE-p5)
2009-06-10 10:31:11 UTC (RELENG_6_3, 6.3-RELEASE-p11)
CVE Name: CVE-2009-1252

For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit .

We very clearly see all affected FreeBSD versions which are not end of life.

I. Background

The ntpd(8) daemon is an implementation of the Network Time Protocol (NTP)
used to synchronize the time of a computer system to a reference time
source.

Autokey is a security model for authenticating Network Time Protocol
(NTP) servers to clients, using public key cryptography.

II. Problem Description

The ntpd(8) daemon is prone to a stack-based buffer-overflow when it is
configured to use the 'autokey' security model.

III. Impact

This issue could be exploited to execute arbitrary code in the context of
the service daemon, or crash the service daemon, causing denial-of-service
conditions.

The Background, Problem Description, and Impact are very clear.

IV. Workaround

Use IP based restrictions in ntpd(8) itself or in IP firewalls to
restrict which systems can send NTP packets to ntpd(8).

Note that systems will only be affected if they have the "autokey" option
set in /etc/ntp.conf; FreeBSD does not ship with a default ntp.conf file,
so will not be affected unless this option has been explicitly enabled by
the system administrator.

The workaround is NOT the "solution." Using an IP firewall does not make the FreeBSD "unaffected." The vulnerability is present with or without a firewall.

V. Solution

Perform one of the following:

1) Upgrade your vulnerable system to 6-STABLE, or 7-STABLE, or to the
RELENG_7_2, RELENG_7_1, RELENG_6_4, or RELENG_6_3 security branch
dated after the correction date.

2) To patch your present system:

The following patches have been verified to apply to FreeBSD 6.3, 6.4,
7.1, and 7.2 systems.

a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.

[FreeBSD 6.3]
# fetch http://security.FreeBSD.org/patches/SA-09:11/ntpd63.patch
# fetch http://security.FreeBSD.org/patches/SA-09:11/ntpd63.patch.asc

[FreeBSD 6.4 and 7.x]
# fetch http://security.FreeBSD.org/patches/SA-09:11/ntpd.patch
# fetch http://security.FreeBSD.org/patches/SA-09:11/ntpd.patch.asc

b) Execute the following commands as root:

# cd /usr/src
# patch < /path/to/patch
# cd /usr/src/usr.sbin/ntp/ntpd
# make obj && make depend && make && make install
# /etc/rc.d/ntpd restart

VI. Correction details

The following list contains the revision numbers of each file that was
corrected in FreeBSD.

CVS:

Branch Revision
Path
- -------------------------------------------------------------------------
RELENG_6
src/contrib/ntp/ntpd/ntp_crypto.c 1.1.1.3.8.3
RELENG_6_4
src/UPDATING 1.416.2.40.2.9
src/sys/conf/newvers.sh 1.69.2.18.2.11
src/contrib/ntp/ntpd/ntp_crypto.c 1.1.1.3.8.1.2.2
RELENG_6_3
src/UPDATING 1.416.2.37.2.16
src/sys/conf/newvers.sh 1.69.2.15.2.15
src/contrib/ntp/ntpd/ntp_crypto.c 1.1.1.3.20.2
RELENG_7
src/contrib/ntp/ntpd/ntp_crypto.c 1.1.1.3.18.3
RELENG_7_2
src/UPDATING 1.507.2.23.2.4
src/sys/conf/newvers.sh 1.72.2.11.2.5
src/contrib/ntp/ntpd/ntp_crypto.c 1.1.1.3.18.2.2.1
RELENG_7_1
src/UPDATING 1.507.2.13.2.9
src/sys/conf/newvers.sh 1.72.2.9.2.10
src/contrib/ntp/ntpd/ntp_crypto.c 1.1.1.3.18.1.2.2
- -------------------------------------------------------------------------

Subversion:

Branch/path Revision
- -------------------------------------------------------------------------
stable/6/ r193893
releng/6.4/ r193893
releng/6.3/ r193893
stable/7/ r193893
releng/7.2/ r193893
releng/7.1/ r193893
- -------------------------------------------------------------------------

Administrators and users have multiple options to fix the system. Not listed is using FreeBSD Update to perform a binary update, which I personally prefer. Furthermore, using this information, we can determine exactly what the problem is.

First, we can download http://security.freebsd.org/patches/SA-09:11/ntpd.patch and see the patch itself in clear text.

Second, we can visit the http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/ntp/ntpd/ntp_crypto.c CVS tree for ntp_crypto.c to find the vulnerable code. We can then review changes between vulnerable and patched versions ourselves.

VII. References

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1252

The latest revision of this advisory is available at
http://security.FreeBSD.org/advisories/FreeBSD-SA-09:11.ntpd.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)

iEYEARECAAYFAkovjOwACgkQFdaIBMps37KRpwCfaQF9q8KhElv6LqgFv3DX2h9c
hbEAn2Q0X8Qv8r5OySnhlAw2pMxlxkXK
=Mh2u
-----END PGP SIGNATURE-----

Overall, I prefer this level of transparency. If you think that exposing this level of information is "bad for security," consider the following.

  1. First class intruders know about vulnerabilities before anyone else because they are constantly performing funded research to find them. They produce and test their own exploits.

  2. Second class intruders only need a hint to direct their resources towards identifying vulnerabilities. In other words, once they hear of a weakness in a protocol or service, they swing their attention to that target and develop exploits. They produce and test their own exploits.

  3. Third class intruders know how to reverse engineer vulnerabilities from binary patches released by the vendor. They produce and test their own exploits.

  4. Fourth class intruders use exploits leaked from higher classes to determine if systems are vulnerable. They test others' exploits.

  5. Administrators without Blue and Red teaming capabilities have to trust that the vendor is honest and competent. They can't test anything so they don't know if they are really vulnerable or not, pre- or post-patch.


So, keeping source code hidden only really hinders fourth class intruders to a certain degree, and it definitely hinders administrators who lack Blue and Red capabilities.

6 comments:

guly said...

this makes no sense.
just as example, php is opensource but *nobody* knows nothing about security update. yes, you can make your own diff between releases and read the code but without comment this is very close to closed source apps.
this is not about open/closed source, it's about disclosure.

Richard Bejtlich said...

guly, I disagree. How can being able to read the code be the same as not being able to read the code? It took me less than a minute to find what I needed on the FreeBSD CVS page.

Michael said...

There are two related issues at work here - Disclosure and Open Source. I think this article makes the case for the former more strongly than the latter.

The FreeBSD Security Team puts out these advisories publicly where many closed source vendors simply release a nebulous "Security Update" (possibly with CVE IDs).

The disclosure of holes raises awareness of security vulnerabilities and gives responsible admins a reliable secure (PGP signed) way of determining if their system is vulnerable and what they need to do to correct the vulnerability if their systems are affected.

The fact that you can track through the source and verify the fix (or check your build tree and see if the fix is applied based on the CVS ID tag) is secondary in my opinion. It's good to be able to verify the fix, but how many admins actually do that? Unless I personally reported a problem & am helping to test/debug a patch I generally trust that the committers "did right".

guly said...

i'm not talkin about "reading the upgrade code", my focus is on the advisory itself. you compared open/closed source with advisory "clearness".
that's obvious, if you can/want to read the code you need it opensource..but the main problem here is that advisory use to be crappy. and here open/closed doesn't matter, that's all about disclosure.

newsoft said...

In the end, I wonder how multiple trivial stack-based buffer overflows, based on poor usage of strcpy(), could end up in the critical "ntp_crypto.c" file ...

Sorry, but I'd rather stick to my operating system, which codebase has been reviewed by paid professionnals, source code has been statically analyzed, compiler does not allow strcpy() use at all, and runtime protections render exploitation of stack-based overflows unpractical ...

Guess which it is (hint: it is the same as Brad Spengler ;).

fheigl said...

completely sidetracking:

I still found this vulnerability the single most funny of the last 5 years.

NTP autokey+multicast client and server modes is one of the coolest features ever invented in a low-level system daemon, especially for security purposes Read up on it, I won't explain.

I've tried to use autokey back in 2002 and read up a lot on it. I will bet $100 that noone will be able to bring forward 30 individuals or companies that successfully set up autokey with NTP multicast server/client mode. If anyone (outside DARPA) runs this they probably bought it as an appliance, and to my experience, most NTP appliances don't include any sophisticated features, either.

This is what makes the bug funny:
The autokey has never received 1% of the attention it had after these advisories. The number of people affected is unmeasurably low as, to be affected, you have to successfully configure it :)