[conspire] (forw) Re: linux & viruses

[Rick Moen]

Aargh!  ;->

With luck, this will be amusing and possibly interesting, despite my
venting grouchiness in it.  If y'all want to further discuss this,
that's fine by me, but I'll probably not participate for reasons that
will become apparent.

My correspondent had written to me with his reaction to
http://linuxmafia.com/~rick/faq/#virus (and related essays following
that) on my "rants" page.  This was my reply:

----- Forwarded message from Rick Moen <rick at linuxmafia.com> -----

Date: Sun, 29 Jun 2003 12:01:05 -0700
From: Rick Moen <rick at linuxmafia.com>
To: [a good guy I know, whose name I'm snipping]
Subject: Re: linux & viruses

Hi, [name snipped].  Thanks (er, sort of) for your note.  I'm going to
start polite, and by the time you reach the bottom, I hope you're not
going to be annoyed, even though this is not really going to go well --
because, with luck, you'll understand why I don't enjoy doing these
things and very much wish them to _go away_.


A prefatory note, and please don't take this as criticism but rather
just as background information:  The usual reason I write those "rants"
is basically to write about a subject for the _last_ time, because it's
a subject I've gotten sick to death of.  In other words, my intention is
to write something I can subsequently refer people to _instead_ of
discussing the matter yet again.

So, I'm glad to discuss this with you once.  If our discussion suggests
ways I might easily improve the essay to make the points clearer and
reduce the likelihood of people wanting to re-argue them with me, I will
actually be grateful.  If you end up deciding I'm bloody well wrong  ;->  ,
then that's perfectly fine but I'll be fine with discussing the matter
through only a single round, probably.

In short, the purpose of my rant essays is _not_ to find out whether
people agree with me.  It is _not_ to convince people.  It is to express
my current views on particular subjects unambiguously and definitively
so that people (ideally) understand those views and I can avoid further
recapitulating of discussions I long ago got tired of repeating.

You got that?  In that context, you'll (with luck) understand my
sometimes becoming grouchy when people nonetheless want to go through
this stuff _yet again_, despite my determined, specific efforts to
dispose of the subject.


Quoting [name snipped]:

>     COUNTERPOINT: Lindows runs everything as root, including the
> mail-reading.

I'm told that it no longer defaults upon installation to auto-login as
the root user.  Until I heard this, my Web pages listed it as the only
Linux distribution _specifically recommended against_, and I had a
policy of letting people know that.

That having been said, until the recent (reported) change to its
installation routine, LindowsOS _did_ nonetheless have full features for
operating normally with distinctions between ordinary and privileged
accounts and ownership/rights to match.  The only objectionable feature
was a display manager with autologin capability whose installation
default was to autologin the root user.  (In consequence, even in those
days, it was a dead-easy misfeature for the admin to correct.  Its fault 
lay in encouraging users to do the wrong thing, _not_ in substantively
preventing them from doing the right thing.)

> Many (most?) single-user Linux systems are run as root interactively
> for non-critical tasks.

I and the entire rest of the long-time Linux user community strongly
discourage this practice whenever we encounter it, as part of the
acculturation process.  It's the equivalent of putting copper pennies in
all your fuseholders because you get tired of replacing fuses.  We
attempt to enforce the acculturation process through, among other
things, _always_ stating assistance advice in terms that emphasise proper
use of privileged [E]UIDs, and _always_ extending basically zero sympathy
to people who damage their systems by reckless and needless use of root
authority.  We treat them basically like kids who've ridden their
bicycles facing backwards, crashed into concrete walls, and gotten
concussions:  We're vaguely sympathetic, hope they get well soon, and 
(when they're conscious again) will politely say "Gee, that hurt, didn't
it?  Would you like some help learning not to hurt yourself in the
future?"

> It's just too annoying having to context-switch all the time just to
> install a new package from CPAN.

o  "su -"
o  "sudo [foo]"
o  "ssh -X username at localhost" (for X11 apps)

I'm sorry, that's simply no excuse.  Not for you, not for me, not for
new users either.  You'll get the exact same bare-minimal sympathy
tinged with pity that I'd extend to a raw newbie, when (not if) you
screw your system.

Please note:  My essays already address the above "counterpoint" of
yours.

>     POINT: A virus picked up by a non-root user couldn't use an exploit
> because this would require a library of exploits, which violates the
> philosophy of viruses.

This is _nothing at all_ like what I said. 

It's a really bad sign when the reader starts making noises like this,
failing hideously to comprehend basic points.  As we will see, things go
downhill from here.

>     COUNTERPOINT: I didn't get this one at all.

It seems not.  (Hmm, that sounded _much_ harsher than I intended.
Apologies; this really is a topic I'm kinda tired of.  Not your fault,
so I shouldn't take it out on you.)

(Actually, I do get harsher by far, but that's yet to come.)

> Each exploit tends to be very small and the shell-code and
> post-penetration code would be shared.  I bet with a 150KB attachment
> you could nail at least 50-100 vulnerabilities.

Tell you what:  Write it and solve the problem of unobtrusive
distribution _and_ getting users dumb enough to run it.  Then we'll
talk. 

Please note that automated local use of such exploits assumes people
with vulnerable software installed such that it runs privileged.  One of
the other things we old-timers try to educate people about is the risks
inherently posed by SUID/GUID root & equivalent binaries, and the need
to minimise their number.  For example, I always advise new admins to
do:

# find / -perm -4000 -print > ~/SUIDS
# find / -perm -2000 -print > ~/SGIDS

...and then remove those bits from any binary without a known need for
them.  (The admin can restore that bit if it subsequently turns out to
be needed.)

>     POINT: Linux is too diverse to effectively attack.

This is _not_ what I said.  I said diversity is one factor among many
that makes wide attacks unlikely to succeed.

>     COUNTERPOINT: There are a small number of distributions responsible for
> the majority of Linux deployments. RedHat seems an obvious candidate for
> targeting. If you could penetrate a RedHat system, you'd nail a large
> percentage of Linux deployments.

One, I'm couching my essay at the intelligent reader, not the moron,
do-something-because-the-herd-does reader.  Two, even Red Hat systems
are diverse, _especially_ if intelligently administered.  E.g., even
though RH through 7.x came with BIND8, only morons failed to replace
that with BIND9 or something better such as MaraDNS -- because BIND8's
fatal long-term faults were way past notorious at that point.  Ditto
sendmail versus Postfix or Exim.  Ditto that piece of shit wu-ftpd, for
which _even_ perennially clueless Red Hat, Inc. now ships (right on the
base CDs) vs-ftpd as an alternative choice.  Three, since much
theoretical "virus" attacks rely on a particular process being not only
installed but also resident in memory (e.g., attacks that rely on
malware mail being received by a particular MUA), useful diversity
exists in the fact that, e.g., there are dozens of popular MUAs from the
115 known for Linux (see:
http://linuxmafia.com/~rick/linux-info/applications-muas.html) and
(e.g.) there are some half-dozen popular Web browser for Linux with
decreased likelihood of common failure modes: Mozilla 1.2.x,
Mozilla-Firebird, Galeon, Konqueror, Opera, Netscape Communicator, 
Dillo.

At this point, _even_ Red Hat, often historically the most irresponsibly
and cluelessly designed of major distributions, no longer pushes users
towards kitchen-sink installations.  Therefore, many installations,
especially those installed thoughtfully, no longer present such a
target-rich and uniform environment.  (Please note that Red Hat exists
for SPARC, PPC, and Alpha in addition to i386, though these were always
minority CPU platforms.)  It is also the case that exploits are not
necessarily backwards compatible, in that a canned exploit against
package foo v. 5.2 will not necessarily work against all foo v. < 5.2. 

So, granting that i386 "Red Hat" (which of course is actually a
multitude of release versions, about which see the final point in the
prior paragraph) is believed to be very popular -- which is an unproven
assumption, given that counting actual in-use numbers of installations
is known to be a very difficult statistical problem -- the uniformity
only of those systems is certainly greatly less than you would imply.

Last, relevant to your current point, we come around to what happens if
a Red Hat (any release version) meets even _bare minimum_ standards of 
marginal competence at maintenance.  E.g., he activates his
free-of-charge subscription to Red Hat Network, which "pushes" to his
system security updates issued by Red Hat, Inc. for known
vulnerabilities.

This has in fact been the _norm_ for all Red Hat releases of the last
few years, going a considerable distance to repair Red Hat's previously
richly deserved reputation for abysmal security.  My fairly firm
recollection is that recent versions' installers make this the _path of
least resistance_ for even inept admins.  So, I'm left wondering what
hypothetical canned exploits you believe would tend to be effective
against randomly selected Red Hat (any recent release version)
installations -- given the pretty nearly 100% automatic security
updating process in place by default.

So, in short, it looks to me like a case of radically less substance
than statements like "If you could penetrate a RedHat system, you'd nail
a large percentage of Linux deployments" might suggest at first glance.

>     POINT: Emacs macros are stored in plaintext, making it less likely
> someone would be so silly as to execute it.

>     COUNTERPOINT: So are .VBS files on windows, and yet this remains one of
> the primary attack vectors. 

You are ignoring the central point:  MS-Windows users' culture is so
brain-dead that it doesn't occur to those users to _look_ at such a
file, because they've been trained to treat files as things you "open"
using the association with the concealed-by-default filename extension.  
(This term "open" conflates the vitally distinct concepts of executing
and viewing a file.)

> Just because you can read the (obfuscated) source doesn't mean someone
> won't click on the "MichaelJackson.mp3.vbs".

One key point -- which I'm quite sure is actually explicit in my
#virus essay (and the three related ones that follow) -- is that Unix
culture reinforces the protections afforded by the technology, and
vice-versa.  In Unix, if you receive an executable in your MUA, you
cannot "double-click" on it.  You can save it to /tmp or ~, but that
will save it _without_ the executable bit by default.  (You can verify,
if you like, that all 115 available Linux MUAs observe this culturally
enforced tradition; I've spot-checked them:
http://linuxmafia.com/~rick/linux-info/applications-muas.html .)

With MUAs, in theory you can also subvert the fuzzy distinction that
sometimes exists between data and executable bitstreams, e.g., using a
malware PDF or PostScript attachment to an e-mail, trusting that some
MUAs might hand them off in some insufficiently cautious way to an
external application via MIME handling.  However, MUA authors and
Linux-distribution assemblers are somewhat kept on their toes regarding
this matter by, well, people like me who are aware of the hazards and
check how the files are handled.  (This, again, is relevant to my point
about Unix culture and technology creating mutually reinforcing
protections.)

By the way, are we having fun, yet?  These discussions pretty much
always tend to become interminable because they tend to branch out from
the ostensibly simple question of viruses into pretty much every aspect
of security.  My #virus, #virus2, (etc.) essays _started_ out being
simple, short, and clear, as originally written.  Lots of people then
have written in over the years, editorialising on either things they
think I've been unclear about or points they think I should have covered
-- so, I've patched the text here, extended it there, and thus it's
arrived at its current over-long state:  arguably the expository
equivalent of spaghetti code.  And somehow, that very length and
complexity makes it easier for _additional_ readers to miscomprehend
fundamentally (or miss) the key points.  So, basically I can't win.

Some day, I may decide to refactor the text, and basically atttempt to
rewrite the stuff top to bottom, to reorganise and revamp it.  But that
will take hideous amounts of time to do properly, so it won't happen
soon.


> One thing that makes Linux a little more scary from a user-security
> perspective is the lack of special extensions identifying a file as being
> executable. 

That's not a bug; that's a feature.  The notion of identifying a file's
nature by its filename extension is _precisely_ one of the worst ways in
which MS-Windows tends to lead users down the garden path, even ignoring
the matter of filename extensions being concealed from the user by
default.  Practically all of the e-mailed MS-Windows trojans, for
example, rely on misleading the user using faked "extensions" in
reliance on this misfeature, e.g., by naming the malware file
"MichaelJackson.mp3.vbs".  Or, worse, the file will mislead the user by
having MIME typing different from the filename extension, leveraging the
misdesign of Microsoft Corporation abortions like MS-Internet Explorer
[spit] that sometimes incomprehensibly decide to heed the latter and
ignore the former.

Moreover, an MS-Windows user who actually _does_ attempt to take
responsibility for executing code, and who overcomes MS-Windows's
default concealing of filename extensions, typically doesn't have a
prayer of actually learning to recognise all the executable types'
mind-numbing array of three-letter extensions.  Consider (again, since
you yourself raised the point) how the ".VBS" debacle decimated the
MS-Windows user community after Microsoft Corp. sprung the MS-Windows
Scripting Engine on them with little notice.

But mostly, what kind of incompetent designer would actually _willingly_
base file typing on filename extensions?  That's just hideously bad
engineering.  The Unix tradition of using magic(1) and the stat(2)
system call -- and the MIME extension of that system -- are both easier
to manage, less painfully cluttered, and more difficult to abuse.

> But on Linux I could have a ".mp3" file that was actually an ELF and
> the OS (if the file was +x'ed) would happily run it.

Haven't you ever heard the "Doctor, doctor, it _hurts_ when I do this"
technical-support joke?  What sort of moron would chmod u+x an
untrustworthy binary file and run it?  Have you learned nothing about
elementary system operations?  How the hell would an .mp3 otherwise
acquire the executable bit?  And what horribly broken "OS" [sic] code
would then be willing to run it without running stat(2) on it to check
its header to find out what it _really_ was?

> Namely, the fact that the file is actually an ELF executable that the
> OS knows how to natively execute is visible only to the kernel, not
> the user. This makes me uncomfortable. 

Then, I suspect you re-think the matter from top to bottom, because, if
you think storing file-typing in three-letter filename extensions
instead of more rigourously determining it from direct inspection of the
file contents using stat(2) makes you _safer_ (!), then you are
dangerously deluded.

> Because now, a friend could send to you a .JPG file to look at. If the
> mailreader was silly enough, you could find yourself running an
> unintended program.

There are 115 Linux MUAs.  Find me one that's that horribly broken, and
the Linux community will pummel its author into a bloody pulp.  What, do
you _actually_ think nobody's been thinking about this, and freakin'
well thinking it over in great detail for decades, [name snipped]?
Because we have, and it merely seems like you're new to the party and
are presuming to raise alarms over _elementary_ aspects of matters we've
been working hard on nailing down tight when you were not paying
attention.

> You seem to have a general philosophy that Linux users are smart. 

This is _not_ what I said.  In fact, when you finally get around to
reading and comprehending what I _did_ say, you will perhaps get my
point about how some protection is built into the technology and some
into the culture.  The two are self-reinforcing, and both slowly and
gradually seep into new users.  Some users insist on learning the hard
way, e.g., by wielding the root account needlessly.  Those people get
educated somewhat by people saying "don't do that" and telling them how
to avoid the mistake, but often are primarily taught by being banged on
the head by Papa Darwin and _then_ being reminded by the rest of us
"Well, that _hurt_, didn't it?  Would you like me to tell you how to
stop aiming at your foot, now?"

> It is true that right now, since Linux is harder to set up and use,
> that Linux users do tend to have a deeper understanding of computing &
> security than Windows users. But with the inevitable success of RedHat
> / Lindows / other distributions that make it easy for grandma to be
> running Linux without knowing it, do you really expect this argument
> to continue to hold water?  Can you really remain confident in
> statements like "A LINUX user surely wouldn't do XYZ."?

This paragraph of yours, more than any of your others, suggests strongly
to me that you didn't bother to attentively read what I wrote at all,
because I address (in my essays) this misperception (misconception) in
very strong and colourful terms, if memory serves.  Let's see, where was
that.  Ah, here:

   Last, you say, surely sysadmins stupid enough to take dangerous
   actions as root must be becoming the norm instead of a rarity, given
   Linux's current explosive growth -- thus undermining the whole security
   model. This, too, is true -- but there are powerful forces at work to
   educate new sysadmins: The administrative tools, themselves, tend to
   stress that the root account is dangerous and should be used minimally
   and carefully, as does Linux's new-user documentation. Also, those
   sysadmins resistant to learning this message via such avenues inevitably
   learn it the hard way, by destroying or crippling their systems
   repeatedly -- until they learn. In that regard, viruses do not even
   stand out from the general likelihood of repeatedly destroying one's
   system, until one learns to not do unwise things as root. The difference
   between "hostile" executables (such as viruses) and others is academic,
   when a root-account user can already shoot off his foot or other vital
   parts, with one of myriad, brief commands. Put the other way, the same
   survival skills by which you, as a novice sysadmin, will cease
   destroying your system directly will also, more generally, dissuade you
   from doing unwise things as root, thereby incidentally keeping viruses
   and their kin off your system.

   Or, put a third way, the Linux community would see no real distinction
   between novices who (as root) infect their systems (if this should ever
   happen to significant numbers of them), and those who accidentally type
   some variation on "rm -rf /" (delete all files) while logged in as root:
   Both are a result of inexperience and lack of caution. In both cases,
   education, attention, and experience are a 100% effective cure. 

Now, will you freakin' well _read_ the thing?  I fscking well shouldn't
have had to basically _read it to you_, now, should I?

> One point that you fail to bring up is the possibility of multiple vectors,
> of which email viruses are but one portion - something more akin to the
> worm/virus hybrids that terrorized Windows networks. 

This would be basically a dumb digression:  Again, the fact that you
even suggest this suggests that you haven't understood key points of my
essay.  The fact that mail-delivered malware could theoretically visit
this-or-that apocalyptic terror upon an unsuspecting world _if executed_
becomes a matter of no interest if it simply doesn't get executed.  My
essay goes into the cutural and technical protections that -- through no
accident whatsoever -- make it unlikely that such code will be executed.

> A user opens up an infected mail 
         ^^^^^

When you say "open", are you indulging that brain-damaged Redmondian
mindset that conflates both viewing and executing under the single
umbrella concept of "opening" a file?  As mentioned previously, this
sort of diseased user culture, more than anything else, is what keeps
the MS-Windows user community helpless to protect its own interests.

In fact, on all 115 Linux MUAs (in both their separate state and as
packaged by various distributions), what happens what a user views an
e-mail is continually subjected to paranoid scrutiny by people like me,
who care rather considerably that this area not become one in which
screw-ups are tolerated -- and accidental ones are caught early and
corrected.

> Most intranets are notoriously poorly secured. 

So, what else is new?  [name snipped], I fscking well hope you don't
think you're teaching something new, here, to a professional WAN/LAN
consultant.


> All it would take is one silly user running Lindows to bring an
> organization of 1000 to its knees. 

What a fetid pile of dingo's kidneys, [name snipped].   Stop talking
rubbish.  If you think you're not talking rubbish, then _try_ to be
specific, and stop doing the verbal equivalent of waving your arms
madly.

For God's sake, man, _think_.  First of all, processes don't fscking run
themselves.  Even if some bonehead user chooses to run some Linux
distribution as root all the time, e.g., some _old_ (not current)
release of LindowsOS that defaults to autologin in that state, that
doesn't magically execute anything, let alone "bring an organization of
1000" to its knees.

In point of fact, if some crappy Linux MUA were so unbelievably broken
as to autoexecute a received binary attachment, then it wouldn't
freakin' well _need_ root authority in order to attack the internal
company network, now, would it?  Thus, whether it's an obsolete version
of LindowsOS, Slackware, Gentoo, or MyFavoriteToyLinux is utterly
irrelevant to your example, isn't it?

> So your essay doesn't leave me any more heartened that Linux is
> fundamentally a platform that's safe from viruses. 

Ask me if I care.  (Actually, don't.)

And I DID NOT SAY that it's "safe from viruses".  For the love of God,
try fscking well READING WHAT I WROTE, next time.


OK, that was Round One.  Please, no Round Two, because this has been
pretty nearly a complete waste of my time and yours.

-- 
Cheers,              First they came for the verbs, and I said nothing, for
Rick Moen            verbing weirds language.  Then, they arrival for the nouns
rick at linuxmafia.com  and I speech nothing, for I no verbs. - Peter Ellis

----- End forwarded message -----