6th Issue of BSD Magazine

The 6th issue of BSD Magazine is available now. This edition has several great articles. I liked Jan Stedehouder's article on Triple booting Windows 7, Ubuntu 9.04 and PC-BSD 7.1, Christian Brueffer's article on FreeBSD Security Event Auditing, and the Questions and Answer Session of the BSD Certification Group Community with Dru Lavigne and Mikel King.

I've been working with the editor at BSD Magazine to publish my articles on keeping FreeBSD up-to-date, so I expect to see them in print within the next few months.

Read More

Hakin9 Extended Edition in Stores

Hakin9 published an "extended edition" magazine recently. This "best of" issue is 218 pages long and contains a nice selection of past articles.

Although the writing isn't as uniformly smooth as one would find in the late, great Sys Admin magazine, I continue to find interesting articles in Hakin9. (By "smooth" I mean that articles written by non-native speakers tend to reflect that English isn't their first language. Hakin9 might consider hiring a native English copyeditor to rework articles prior to publication.)

There's really no other printed security periodical like Hakin9. The technical level is higher than that of 2600 magazine, for example. You don't find articles on security management like you might in Information Security Magazine or SC Magazine, either.

Read More

Security Information and Event Management (SIEM) Position in GE-CIRT

My team just opened a position for a Security Information and Event Management professional. This candidate will report to me in GE-CIRT but take daily direction from our SIM leader and our Lead Incident Handler. We're looking for a technical person who can not only administer our SIM, but also help our team implement our detection and response objectives and use cases in our SIM and related infrastructure.

This candidate will sit in our new Advanced Manufacturing & Software Technology Center in Van Buren Township, Michigan.

If interested, search for job 1087025 at ge.com/careers or go to the job site to get to the search function a little faster. I am available to answer questions on the role or forward them to our SIM leader. You can reach me by posting a comment here and providing an email address where I can contact you. Thank you.

Read More

Information Security Position in GE Aviation

My colleagues in GE Aviation are looking for a candidate for a client computing architect. The focus will be Microsoft Windows platforms. According to the hiring manager, the following are desired:

• 50% leadership / 50% technical mix


• Strong leadership, program management, and influence skills


• Strong communication skills; the candidate will work with business and Corporate teams


• Security and technical skills, such as a strong command of Windows features and defenses

If interested, search for job 1055733 at ge.com/careers or go to the job site to get to the search function a little faster. Please do not contact me directly. Thank you.

Read More

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.

Read More

Microsoft Updates MS09-048 to Show XP Vulnerable to 2 of 3 CVEs

Microsoft published a Major Revision of MS09-048 to show that Windows XP Service Pack 2 and Windows XP Service Pack 3* are now Affected Software.

This is an important development. It is significant to acknowledge that an operating system is vulnerable despite the potential to add a countermeasure. In other words, countermeasures do not remove vulnerabilities.

The company also updated the FAQ:

If Windows XP is listed as an affected product, why is Microsoft not issuing an update for it?

By default, Windows XP Service Pack 2, Windows XP Service Pack 3, and Windows XP Professional x64 Edition Service Pack 2 do not have a listening service configured in the client firewall and are therefore not affected by this vulnerability. The denial of service attacks require a sustained flood of specially crafted TCP packets, and the system will recover once the flood ceases. This makes the severity rating Low for Windows XP. Additionally, Windows XP Service Pack 2 and later operating systems include a stateful host firewall that provides protection for computers against incoming traffic from the Internet or from neighboring network devices on a private network.

Windows XP is not affected by CVE-2009-1925.

As you can see, Microsoft is sticking with the "firewall" defense (and they forgot to remove the "not affected by this vulnerability" language from version 1.0 of the bulletin. This is still not acceptable.

Microsoft did clarify that CVE-2009-1925, TCP/IP Timestamps Code Execution Vulnerability, does not apply to Windows XP. That is good news.

So, what can you do? I would like to hear from anyone who is testing XP SP2 or SP3 for TCP/IP Zero Window Size Vulnerability - CVE-2008-4609 and TCP/IP Orphaned Connections Vulnerability - CVE-2009-1926. How does XP respond? Thus far @jkrage mentioned blue screens for the two DoS conditions. Can anyone else reproduce this? If yes, how?

Thank you.

Read More

MS09-048 on Windows XP: Too Hard to Fix

This is a follow-up to MS09-048 is Microsoft's Revenge Against XP in the Enterprise. Everyone is talking about how Windows 2000 will not receive a patch for MS09-048:

If Microsoft Windows 2000 Service Pack 4 is listed as an affected product, why is Microsoft not issuing an update for it?

The architecture to properly support TCP/IP protection does not exist on Microsoft Windows 2000 systems, making it infeasible to build the fix for Microsoft Windows 2000 Service Pack 4 to eliminate the vulnerability. To do so would require rearchitecting a very significant amount of the Microsoft Windows 2000 Service Pack 4 operating system, not just the affected component. The product of such a rearchitecture effort would be sufficiently incompatible with Microsoft Windows 2000 Service Pack 4 that there would be no assurance that applications designed to run on Microsoft Windows 2000 Service Pack 4 would continue to operate on the updated system.

Let's think about that for a minute. Vista's TCP/IP stack is the Next Generation TCP/IP Stack. This means XP shares at least some of the TCP/IP stack of Windows 2000. Microsoft (as noted in my last post) didn't patch XP because it said the client firewall mitigated the problem, as long as you don't expose any ports -- not because XP is invulnerable. From what we can gather, XP is at least vulnerable to the two DoS flaws (TCP/IP Zero Window Size Vulnerability - CVE-2008-4609 and TCP/IP Orphaned Connections Vulnerability - CVE-2009-1926).

In other words, patching Windows XP is also architecturally "infeasible."

This appears to be more than a theory. Just about the only straight answer I could get from a Microsoft rep this evening was the answer that MS09-048 is too hard to fix on XP, just like it was too hard to fix on 2000.

I think it's time to tell Microsoft this situation is not acceptable.

Read More