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.

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.
10:13 AM
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.
10:19 AM
voretaq7 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".
10:53 AM
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.
12:14 PM
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 ;).
4:25 AM
darkfader 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 :)
12:48 PM
Post a Comment

Popular posts from this blog

Zeek in Action Videos

Image
This is a quick note to point blog readers to my Zeek in Action YouTube video series for the Zeek network security monitoring project .  Each video addresses a topic that I think might be of interest to people trying to understand their network using Zeek and adjacent tools and approaches, like Suricata, Wireshark, and so on.  I am especially pleased with Video 6 on monitoring wireless networks . It took me several weeks to research material for this video. I had to buy new hardware and experiment with a Linux distro that I had not used before -- Parrot .  Please like and subscribe, and let me know if there is a topic you think might make a good video.
Read more

MITRE ATT&CK Tactics Are Not Tactics

Image
Just what are "tactics"? Introduction MITRE ATT&CK  is a great resource, but something about it has bothered me since I first heard about it several years ago. It's a minor point, but I wanted to document it in case it confuses anyone else. The MITRE ATT&CK Design and Philosophy document from March 2020 says the following: At a high-level, ATT&CK is a behavioral model that consists of the following core components: • Tactics, denoting short-term, tactical adversary goals during an attack; • Techniques, describing the means by which adversaries achieve tactical goals; • Sub-techniques, describing more specific means by which adversaries achieve tactical goals at a lower level than techniques; and • Documented adversary usage of techniques, their procedures, and other metadata. My concern is with MITRE's definition of "tactics" as "short-term, tactical adversary goals during an attack," which is oddly recursive. The key word in the tacti...
Read more

New Book! The Best of TaoSecurity Blog, Volume 4

Image
  I've completed the TaoSecurity Blog book series . The new book is  The Best of TaoSecurity Blog, Volume 4: Beyond the Blog with Articles, Testimony, and Scholarship .  It's available now for Kindle , and I'm working on the print edition.  I'm running a 50% off promo on Volumes 1-3 on Kindle through midnight 20 April. Take advantage before the prices go back up. I described the new title thus: Go beyond TaoSecurity Blog with this new volume from author Richard Bejtlich. In the first three volumes of the series, Mr. Bejtlich selected and republished the very best entries from 18 years of writing and over 18 million blog views, along with commentaries and additional material.  In this title, Mr. Bejtlich collects material that has not been published elsewhere, including articles that are no longer available or are stored in assorted digital or physical archives. Volume 4 offers early white papers that Mr. Bejtlich wrote as a network defender, either for technica...
Read more