See also: last week's Letters page.

Letters to the editor

From:	 Phil Cameron <pcameron@CrescentNetworks.com>
To:	 letters@lwn.net, pecameron@mediaone.net
Subject: Security perspective
Date:	 Thu, 07 Feb 2002 12:56:48 -0500

There are a couple of more points to consider when counting the security
updates. 
1) Is this a fix for a known exploit or is it a fix for something that
can happen in theory.
2) What damage can be caused by the exploit?

Looking at this weeks updates:
Mandrake Linux Security Update - GZIP: 
This fixes two problems with the gzip archiving program; the first is a
crash when an input file name is over 1020 characters, and the second is
a buffer overflow that could be exploited if gzip is run on a server
such as an FTP server.

The first is not security related and the second looks like an exploit
that can cause damage. Is there a known exploit? A lot of things that
seem possible turn out to not be possible because of the interaction of
other software. 

Net::FTPServer security fix.
close a potential vulnerability "allowing users to list directories to
which they should not have access. If your configuration file uses 'list
rule', then you need to upgrade to version 1.034."

How bad is this? What actual damage can be done? You can't actually
"get" the files, just list them. There doesn't seem to be a known
exploit. Do we count it any way?

PHP Safe Mode Filesystem Circumvention Problem
"If an attacker has access to a MySQL server [...], he can use it as a
proxy by which to download files residing on the [PHP] safe_mode-enabled
web server".

OK how do you count this? Is there a known exploit? What does it take to
gain access to a MySQL server?


Much of the time, we see bugs that are uncovered by reviewing code and
during debugging. Every once in a while a really important vulnerability
is discovered.  How many of these bugs will actually be seen on
production machines? I personally like to see these reports because it
shows that people are taking security seriously and are trying to plug
holes that could possibly exist. The more we do this the stronger the
system gets. It is unfair to compare them with other vendors products
without carefully analyzing the nature of both systems problems.

As for distributions, I would like to see a basic out of the box secure
system. The entire system needs to operate in the secure mode so that
the installer or admin does not have a need to weaken it. Secure out of
the box is value that distributors can add that can distinguish them
from each other.

Phil Cameron

From:	 Armijn Hemel <armijn@nl.linux.org>
To:	 corbet@lwn.net
Subject: .NET stuff
Date:	 Thu, 7 Feb 2002 17:06:34 +0100

hello LWN,

with a lot of interest I've been following all this discussion about Mono
and .NET. One of my former teachers here at the university is now program
manager of the Common Language Runtime for .NET and I've read a few articles
and magazines (issued by Microsoft) about this whole .NET thing.

The .NET concept is indeed very nice. There is a good defined bytecode
language (Intermediate Language, IL), a decent runtime and a set of
compilers for different languages to compile to IL.
Sounds neat, because you can then write stuff you want in one language
and use it in another language. You can specialize in writing the language
that is best suited for the task.

What most people forget is that to ensure that this can happen there
is a specification (the Common Type System, CTS) which describes which
datatypes you can use in a language if you want to take full advantage of
the .NET framework.

A quote from the Microsoft MSDN site about the CTS:

\begin{quote}

The common type system defines how types are declared, used, and managed in
the runtime, and is also an important part of the runtime's support for
cross-language integration. The common type system performs the following
functions:

* Establishes a framework that enables cross-language integration, type
  safety, and high performance code execution.
* Provides an object-oriented model that supports the complete implementation
  of many programming languages.
* Defines rules that languages must follow, which helps ensure that objects
  written in different languages can interact with each other.

\end{quote}

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconthecommontypesystem.asp

So, while .NET does not limit you in the number of programming languages
it does limit how these languages are being used (see the third `function' of
the CTS above), which is (I think) a serious drawback if you want to do real
programming. Therefor I can't understand why Miguel is so positive about the
.NET framework...

armijn

-- 
 ---------------------------------------------------------------------------
   armijn@nl.linux.org | http://people.nl.linux.org/~armijn/ | Penguin Power
 ---------------------------------------------------------------------------
                 http://nl.linux.org/ | Alles over Linux
 ---------------------------------------------------------------------------

From:	 dps@io.stargate.co.uk
To:	 letters@lwn.net
Subject: Region coding---the truth vs. what is said
Date:	 Thu, 7 Feb 2002 18:44:36 GMT

I think most people believe the real reason for region coding
DVDs is that people can charge more for less in europe. The
studios would deny it but that is probably because saying so
would leave them liable to unpleasant prosection (under consumer
protection and free trade statutes). Let it suffice to say the
same DVD costs a lot less if bought in america... and you
might get more on the american version too.

I am fairly sure that what was said in court was that DeCSS and
other efforts that allow people to exervise their fair use rights
should not be allowed becuase that would allow piracy. The logic
is a little flimsy, for example I could just record the video
signal on a good quality video recorder and probably get something
close to the quality of the DVD, but when did logic get in the way
of attempting to abuse the law? Legal niceties like terms that are
legally null and void in licence agreements, because those terms
are illegal, are still present (the mnost common is the "by openning
this envelope you agree to these terms" language---legal advice is
that this has no force in the UK).

Fortunately america can not unilatterally abolish limits to their
juristiction, and the DMCA does not apply in europe. Even if it
did extradition to america is dubious because much of europe will
not allow extradition to anywhere with the death penality (and
defninitely not if the death penality might be applied).

P.S. As a person with no TV, sound card, or DVD reading equipment
the obvious DVD practices do not affect me. I am thinking about
a DVD writer for backing up *my own* data (CDs are just too
small).

From:	 jimd@starshine.org (Jim Dennis)
To:	 letters@lwn.net
Subject: chkrootkit and System Integrity Auditing
Date:	 Thu,  7 Feb 2002 16:10:07 -0800 (PST)

 Hi,

 The fundamental problem with any tool like tripwire, aide,
 chkrootkit, or any other system integrity system (including
 virus scanners under other operating systems) is that they
 MUST BE RUN FROM A KNOWN CLEAN SYSTEM BOOT.

 That is the first, foremost, and inescapable rules of 
 system integrity auditing.  You must boot from known clean,
 write-protected media.

 I realize that this advice rankles sysadmins with an
 uptime fetish.  However, I want to impress people that it
 is almost invariate.  The only scenario I've imagined where
 I *might* accept the integrity of "hot" system audit would
 be in a case where hardware mirroring or raid would allow me
 to randomly pull a set of system volumes, push them into
 a KNOWN CLEAN standby system and perform the audit therefrom.
 I have not yet implemented such a scenario and would only 
 recommend it for cases where the server had hard and fast 
 uptime requirements that couldn't be met through clustering,
 etc.  (In other words, I might consider that auditing model
 for zSeries and S390 mainframes running 24x7 database 
 services).
 
 That said I have to point out the second inviolable law of 
 system integrity auditing --- you MUST capture the reference
 data (checksums, permissions, backup copies, whatever) 
 BEFORE any exposure.  So, ideally, you install and configure
 the system on a workbench (no network connection), prepare your
 reference data set and then connect the system to your LAN or
 net.  

 My favorite system integrity reference data is a simple tar
 file.  My favorite system auditing technique is:

 	boot from LNX-BBC (or tom's root/boot, or ...)
	mount filesystems
	insert reference media (write-protected tape, CD-R, whatever)
	tar dzf /dev/st0 (or whatever)

 ... this should detect all difference in content, permissions,
 and some innocuous things like timestamps and squawk about them.

 Part of the beauty of this system is that it ensure ready recovery
 from any problems you detect (left as exercise to the student, but
 it might involve replace a 'd' with an 'x').

 Of course the principal disadvantage is that you have to also 
 manage all those nasty updates.  In practice we really care about
 the core kernel, shell, libc, and system utilities (up to and 
 including our gpg, aide, md5sum, and ssh tools).  Then we can
 (after insuring their integrity) reasonably rely on those tools
 for the rest of our tests.

 For Debian systems we can use commands like:
 
 	ar p $PACKAGE data.tar.gz | tar dzf -

 ... to perform a quick and dirty audit of a given package's files 
 versus those under our current directory (at the root of the 
 distribution's installation, but possibly mounted at an arbitrary 
 place because we've booted from BBC/CDR).

 On can perform similar tricks using rpm -Vp ... (though that will be
 checking checksums rather than doing a bit-for-bit comparison).

 I could give a full day class in system integrity auditing techniques.  
 However, these few tips should help.  There are numerous
 alternatives to tripwire/aide (recent versions of tripwire are not
 free).  I recommend installing aide (apt-get-able for Debianistas)
 and one other (more obscure one) like fcheck, viperdb, or maybe a
 custom perl script for redundancy.  Assume that your attacker knows
 about tools like chkrootkit, aide, and tripwire (the big ones) 
 so maintain an extra little surprise for the lazy and careless 
 cracker to miss.

 Having nightly cron job is useful, it will catch the most careless
 and lazy script kiddies.  However, it is wise to assume that your 
 cracker will search or compromise your cron subsystem, so squirrel 
 your backup alarm triggers into more obscure places such as a 
 user's at job (possiblly SUID root, but only executable to their group)
 or perhaps a custom little patch to syslogd, sshd, or some other daemon 
 which spawns the check every day (and sends a heart beat to some other
 system to alert it that *that* daemon hasn't been summarily replaced.)

 I realize that this all sounds like paranoid spy novel stuff.  But
 it's really silly to underestimate your attackers.

 (BTW: any cracker reading this: don't bother attacking my home systems,
 they are uninteresting play toys that are not particularly hardened 
 and my link to the net is a pathetic little IDSL.  There's no sport in
 defacing my web pages because I'm not noted enough for the bragging
 rights to mean anything.  I reserve my real work for giving free advice
 and for paying customers).

--
Jim Dennis,
Starshine Technical Services

From:	 chris.m.moore@amsjv.com
To:	 john.lettice@theregister.co.uk
Subject: The comments on the MS Seatlement
Date:	 Tue, 12 Feb 2002 11:35:02 +0000
Cc:	 letters@lwn.net

Hi,

By labelling the comments which only discuss the RPFJ as a starting
point as "substantive" the DOJ and the Register ("DoJ-MS comments: that
breakdown in full") have dismissed the vast majority of the comments
which "express an overall view of the RPFJ [Revised Proposed Final
Judgment] but do not contain any further discussion of it".

I count the letter I sent in this category (and Hans Reisers too, see
http://linuxpr.com/releases/4445.html).  I dismissed the current
settlement as ineffective (the MS stock price rose after it was
announced) and proposed an alternate solution based on the LGPL (with
certain restrictions to prevent vertical markets forming).  I suspect
many of these 19500 comments would start from the premise that the
current settlement is useless and propose alternatives.

In any battle a general wants to pick the ground on which to fight.  By
picking the RPFJ, the DOJ and MS hopes to curtail further discussion. 
I'm quietly encouraged that the judge has refused the application for a
limited oral hearing on this matter.
 
Chris M. Moore
Software engineer
Portsmouth, UK