Kamis, 10 September 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.

0 komentar:

Posting Komentar