[conspire] "Lupper Worm" and the patching of bad software

Wed Nov 9 11:53:46 PST 2005

From: [a manager]
Sent: Tuesday, November 08, 2005 9:33 AM
To: [a department]
Subject: FW: Linux worm and what do we do?

FYI

----<forwarded post>----

From: [another manager]
Sent: Tuesday, November 08, 2005 11:59 AM
To: [some folks]
Subject: Linux worm and what do we do?

Greetings,

Apparently a worm is out that targets Linux systems:

Lupper worm targets Linux systems
http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1141351,00.html?track=NL-102&ad=533046USCA

It is slow spreading.

So... what is our anti-virus and monitoring strategy for Linux viruses
and worms? 

Thanks, 
[sender]

From: Rick Moen
To: [a department]
Subject: FW: Linux worm and what do we do?

As is traditional for McAfee alerts, you have to search hard to find the
point of interest, which is:  What vulnerability is exploited?  It's
this one sentence; the rest of the advisory is superfluous:

"Sends HTTP requests to the URLs it generates and attempts to spread by
exploiting an XML-RPC for PHP remote code injection vulnerability, an
AWStats rawlog plugin logfile parameter input validation vulnerability
and the Darryl Burgdorf Webhints remote command execution
vulnerability."

General Analysis:

AWstats is a Web log-analysis package written in Perl, one that is
infamous for careless bugs in its input-validation routines.  The
default installation method is as a CGI that generates the stats Web
page dynamically, for each stats-viewing user.  That method combined
with the script's notorious problems with input validation mean that it
has repeatedly been the means for site compromise through feeding it
carefully designed information as part of the URL.  This vulnerability
follows suit, with the additional wrinkle that it works only if the site
also runs the optional AWStats Rawlog Plugin add-in (file rawlog.pm).
AWstats 6.4, released 2005-05-05, fixed the problem.

I stressed that this pattern of vulnerabilities exists when one uses the
default installation method for AWstats:  One can, instead of allowing
AWstats to generate dynamic Web pages on the fly, instead run at cron
job at (say) ten-minute intervals, thereby avoiding that entire category
of problems.  I have a write-up about how to do this, on my personal Web
site.

By "XML-RPC for PHP", McAfee means PHPXMLRPC, an intended successor to
the canonical XML-RPC daemon (which handles inter-application messages
written in XML), written by the PHP maintainers.  By "remote code
injection vulnerability", they mean the announcement on 2005-08-15 that
PHPXMLRPC versions prior to 1.1.1 are vulnerable to an attack because of
(of course) poor input validation, such that the PHP interpreter can be
induced (by unexpectedly nested XML tags) to pass arbitrary PHP
statements to "eval()" calls in the PHP code.  As of v. 1.2 in September
2005, the authors eliminated this entire class of vulnerabilities by
eliminating the eval() function.

The similar PEAR-XML_RPC library 1.3.3 and earlier is also vulnerable.
Report:  http://www.securityfocus.com/bid/14560  1.3.4 is not.

By "the Darryl Burgdorf Webhints remote command execution
vulnerability", McAfee means (yet again) an input-validation weakness in
a CGI Perl script.  WebHints is a frivolous script for the Web to
display a "thought for the day" or such, drawn from a list of same.  The
hints.pl file from WebHints 1.03 allows remote attackers to send
arbitrary commands to be processed by the system shell via
metacharacters in the URL input.

[organisation name] Analysis:

1.  This is not a (specifically) Linux issue.  It applies on any OS
on which the indicated software versions are run.  Yes, the McAfee
article was misleading on that point, but they often are.

2.  I think it unlikely that either AWstats or WebHints is installed on
Linux machines at [organisation name]:  They are not included in RHEL or
SLES.  However, it is possible that they are installed outside the [some
organisational reference] process.

3.  Vulnerable versions of PHPXMLRPC (but not PEAR-XML_RPC) is included
in RHEL3, RHEL4, and SLES.  Patch RPMs:
http://rhn.redhat.com/errata/RHSA-2005-564.html
http://www.novell.com/linux/security/advisories/2005_51_php.html

However, I also think it highly unlikely that anyone at [organisation
name] is running the PHP XML-RPC service:  The affected machines would
have to be running a PHP-based developed application with inter-process
messaging mediated by the vulnerable messaging daemon, and I know of no
such applications.

On a wholly different matter, the
http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1141351,00.html?track=NL-102&ad=533046USCA
article mentioned an ftpd-ssl vulnerability on account of unsafe use of
the sprintf() function for (of course) input validation.  

ftpd-ssl is not included in RHEL or SLES.  Quite a few years ago, I was
among the many people who kept bothering Red Hat over their former
inclusion of a similarly unsafe ftp daemon, the Washington University
ftp daemon (wu-ftpd), and urging them to switch to vs-ftpd (Very Secure
ftp Daemon).  Our campaign worked, and that is exactly what Red Hat have
done for a long time, and Novell/SUSE has done likewise.

Oh, by the way, I should stress, also, that none of those are remote
root exploits:  A successful attack would, in itself, accomplish nothing
more for the intruder than compromising the Web server, e.g., to deface
it.  A broader compromise of the attacked host would require that the
host also have separate, local vulnerabilities that permit escalation of
privilege to the root (or equivalent) user's authority.

From: [a colleague]
Subject:  RE: Linux worm and what do we do?
To: [a department]

Hi,

Sorry I can't resist...

As is said in so many after school specials, "So kids, what have we
learned today?"

A "worm" in the security sense is a Win32-ism.

Being affected by a "Linux worm" means you've been hacked.

Fixing the problem means fixing your code and updating the reliant
packages, if any, as well as implementing a well thought out system
security plan.

Today's show is brought to you by the letter "h", for "you've been
hacked and it's your fault" and the number "0" for the actual cost in
acquiring the tools to fix your problem.

;-)

From: Rick Moen
To: [a department]
Subject: FW: Linux worm and what do we do?

[colleague name], well said.

I'm also slowly developing an (at least partial) allergy to Perl CGI
scripts exposed to hostile networks, since it seems that few authors
bother doing meaningful input validation. The security history of
AWstats is instructive:  The authors keep releasing patches to fix "new"
vulnerabilities, but none of those patches has ever addressed the root
problem of bad design.  Therefore, the patches are ultimately
ineffective.  As the computer said in "War Games", the only way to win
is not to play.

I basically agree with Marcus Ranum on that point:  Patching bad
software is a fool's game.
http://www.ranum.com/security/computer_security/editorials/master-tzu/ 

Choice quotation:

The Tale of Wise Master Tzu and the Prince's Patching Policy

It happened that The Prince of Wu was reading a bunch of Master Tzu's
USENET postings and concluded that Master Tzu was wise in the way of
strategy. Sending his bannermen forth, he offered Master Tzu a golden
Ipod in return for a brief consulting visit in which The Master was to
assess Prince Wu's Patching Policy. Prince Wu had been to numerous
security conferences, and subscribed to the daily scrolls from Master
SANS, and spent 3 hours per day meditating to achieve Security Focus -
he was sure that Master Tzu would be impressed with his efforts and
would position him well in the Magic Quadrant of visionaries. The day
came when Master Tzu came to inspect Prince Wu's fortifications and
Patching Policy. Alighting from his palanquin, which was carried by
mighty slaves, Master Tzu sniffed the air and quickly observed to the
attentive Prince Wu:

If you are fighting a losing battle, it is likely one of three things:
a) You are continuing a trend in a losing war - and therefore should not
   be surprised.
b) You have chosen to fight the wrong battle.
c) You are stupid.

Master Tzu cocked an eyebrow, "Which applies here?" Then he pocketed the
golden Ipod, packetized himself back into his palanquin, and went home.
Prince Wu fell to his knees, enlightened, had his Internet-facing
servants all put to death, and never installed another patch in all his
days.

See also:
http://www.ranum.com/security/computer_security/editorials/dumb/