[owl-users] Openwall t-shirts; Owl-current 2011/10/10 snapshot

Hi,

This is to announce two things at once.  I'll start with the less usual
and shorter announcement:

1. Official Openwall t-shirts are now available from 0-day Clothing:

http://www.zerodayclothing.com/products/openwall.php

Please consider purchasing one of these if you'd like to express your
support for Openwall.  While you're at it, you might also want to check
out other 0-day Clothing designs:

http://www.zerodayclothing.com

2. A new snapshot of Owl-current (Openwall GNU/*/Linux development
branch) is available, including a complete set of components: ISO
images, OpenVZ container templates, binary packages for i686 and x86_64,
and indeed the source code:

http://www.openwall.com/Owl/

Significant changes since the previous set of ISOs and templates (those
of Owl 3.0-stable this time, generated a month ago) include update of
the Linux/OpenVZ kernel to one based on RHEL 5.7's, introduction of
tzdata package with up-to-date timezone data, and a security fix to
Owl's package of RPM (CVE-2011-3378):

http://www.openwall.com/Owl/CHANGES-current.shtml

Obviously, these changes are also meant for inclusion in Owl 3.0-stable
after testing in Owl-current.

With this kernel package update, we're compiling two additional disk
controller drivers into the kernel image (for Adaptec AIC94xx SAS/SATA
and Compaq Smart Array 5xxx controllers).  Because of this and because
RHEL 5.7 kernels are slightly larger than older kernels on their own,
we're moving some other components from the kernel image to modules in
order to keep the kernel image from growing.  This includes some OpenVZ
features, which are normally compiled as modules in OpenVZ's official
kernel builds (so our builds are more similar to theirs in this respect
now).  For this reason, the new kernel packages should be installed at
the same time with our vzctl package update, which has the
MODULES_DISABLED setting in /etc/vz.conf commented out (just like it's
done in upstream's vzctl).  As a side-effect of this change, an Owl
system with at least one OpenVZ container now has more components of
OpenVZ loaded than it would before.  Specifically, "service vz start"
loads optional OpenVZ components and ip_conntrack, which did not happen
before (since these were not built into the kernel image and vzctl's
module loading was disabled).  Here's what the loaded module list looks
like after "service vz start" (with at least one OpenVZ container):

Module                  Size  Used by
vzethdev               14752  0 
simfs                   9752  1 
exportfs                9088  1 simfs
vzrst                 152592  0 
ip_nat                 19600  1 vzrst
vzcpt                 115640  0 
nfs                   253912  2 vzrst,vzcpt
lockd                  69552  2 vzrst,nfs
nfs_acl                 7296  1 nfs
sunrpc                156352  6 vzrst,nfs,lockd,nfs_acl
ip_conntrack           56596  3 vzrst,ip_nat,vzcpt
vzdquota               44792  1 [permanent]
vznetdev               27448  2 
vzmon                  38936  4 vzrst,vzcpt,vznetdev
vzdev                   7304  4 vzethdev,vzdquota,vznetdev,vzmon

In a later revision of vzctl, we might deal with this by making
MODULES_DISABLED tri-state.  Opinions on this are welcome.

The timezone data update is critical for Russia, Ukraine, and Belarus,
which have abolished the switch to "winter time" starting this year.
This switch would take effect on the night from October 29 to October 30,
so the timezone data update must be installed before then.  It may be
installed with the following commands and actions:

rpm -Fvh glibc-*.rpm # Update glibc package thereby removing old timezone data
rpm -Uvh tzdata-*.rpm # Install the tzdata package providing new timezone data
setup # Choose your timezone again in order to have /etc/localtime updated

The two "rpm" commands may be combined into one:

rpm -Uvh glibc-*.rpm tzdata-*.rpm

assuming that you had all sub-packages of glibc installed anyway.

The RPM package manager issue was a crash and potential arbitrary code
execution when processing a malformed/malicious package file.  Although
an RPM package can, by design, execute arbitrary code when installed or
even during installation, this issue would potentially allow a
specially-crafted RPM package to execute arbitrary code when the package
metadata is merely queried, including for digital signature
verification.  Note that for Owl RPM packages we do not rely on RPM's
support for signatures; instead, we sign *.mtree files.  Please continue
to verify detached GnuPG signatures that we provide for such files with
gpg(1), and then verify RPM package files against the message digests
found in *.mtree files with mtree(8) (both of these tools are part of
Owl).  This kind of verification was unaffected by this RPM issue.

Please note that use of RPM on untrusted package files, even if just to
verify a signature, remains risky despite of this recent fix: RPM
package format and processing are complicated, so further issues of this
kind are likely.

The RPM issue was discovered and reported to distribution vendors by
Tavis Ormandy:

http://www.openwall.com/lists/oss-security/2011/09/27/3

Besides the changes in Owl-current mentioned above, certain minor and
development-focused changes have been made as well, such as in
preparation for GCC update to 4.6.x (making many packages ready to build
with this new version of GCC).  These are primarily due to work by
Vasiliy Kulikov.

As usual, any feedback is welcome on owl-users.

Alexander