[conspire] Re: Presentation - typo slide 21

Rick Moen rick at linuxmafia.com
Thu Dec 16 13:17:50 PST 2004

[Note Cc to my mailing list.  Maybe you'll consider joining?]

Quoting Karsten Self (kmself at ix.netcom.com):

> Slide 20:
>     Slapper/Slammer.  AFAICT, about the only person to call this the
>     slapper worm is me, my error.  There was a separate "Slapper"
>     exploit, targeting Apache.

Well, honestly, I think you have as much right to establish a name for
one of these things as anyone else, and a _lot_ of people read what you
wrote on the subject at the time -- so, error or not, it's now part of
the historical record.  (I was well aware of the namespace collision; my
longer pieces such as November's #virus5 essay,
disambiguate it in passing.)  

Still, I'm editing the slide to list your name for the bugger last among
the three.

> Slide 26:
>     Style issue.  I'd standardize the "DO" "DON'T" usage to clarify
>     important steps.

This causes an unfortunate line break, which is why I didn't.  But
There's More Than One Way To Do It:  I've re-edited the slide to use
italics, instead -- and also made each point's sentence begin with "Do"
or "Don't" (italicised).

> Slide 27:
>     Actually, there are a surprising number of malware tools which *do*
>     claim to be good guys.

Which was part of the very consciously intended irony of my point.  I
made sure I drove that point home, thanks.

> General commentary:
> On canaries.  I think this is a really important point....

I'm glad you agree.  I was rather taken with the idea, both as a
pragmatic point and as a way of putting the virus "threat" in its proper
context as a parting insult dealt to your system after you've completely
fucked up in more vital ways.  More about this below.

> ....and perhaps it comes across more clearly in your presentation.  I
> still think it's a bit muddy in the slides.

This is because they're slides, not an essay or article.  Slides are
supposed to be props.  As you yourself commented later:

> Slides:  probably a bit info-dense for a presentation, but nice for
> on-the-web reading.

These were the first slides I've ever created (or used), and I now see
that they ended up being too info-dense by about a factor of three.
That's partly my own inexperience, partly starting way too late, and
partly an artifact of the particular process I used in making them:

As you may recall, my first step (Tuesday) was to create an outline.
Outlines are good and useful -- and happen to correspond well with how my 
mind works on analytical topics -- but just aren't at all similar to
either essays _or_ slides, and should not be confused with them.

Having created the outline, I pretty much dumped it (Wednesday morning)
straight into OO.o Impress in a slightly reshuffled order, and did only
a _little_ tightening up and pruning of wording.  So, what you're seeing
is substantially a talk outline masquerading as a slide presentation.

That's wrong:  Slides are not supposed to be narrative; they're supposed
to be AV aids -- props -- to underline points you make separately during
your presentation.

What I really needed to do was write the outline a week earlier,
reshuffle its contents into the order in which I intended to speak about
them, and then flesh those out into a set of speaker's crib notes to
glance at while speaking.  Then, as a separate and _additional_ step, 
I should have made slides illustrating a small number of key points from
those crib notes that I wanted people to walk out thinking about.

Your comment above ("I still think it's a bit muddy in the slides")
strikes me as reflecting my slides _feeling_ like an essay that's had
some supporting narrative omitted, so one's reaction tends to be "Too
bad this point isn't fleshed out", rather than "What an intriguing list
of bullet points.  Pity I didn't hear the lecture that went with them."

The essay is my natural writing form:  That's why, dammit, even when I
try to make slides, they come out as disfigured essays.

>   - System security is about preventing unauthorized access to data,
>     services, resources, and/or hardware, and preventing unauthorized
>     modification (including deletion/destruction) of same, while
>     ensuring availability to authorized persons for authorized tasks.
>     Security is best discussed in terms of risks (what can be done),
>     threats (who can do it), and costs (how can we guard against R&T).
>     Risks & threats are often described as a "threat model":  possible
>     modes of attack we concern ourselves with.

That's good.  If I'd done a longer talk, I might have used this as an
organising principle.  Still, the four organising principles ("thoughts
to ponder") I listed on slide #5 worked pretty well.

In accordance with what it says on slide #1, I opened my talk by
confessing that this was a Unix security lecture sneakily masquerading
as a virus talk.  Often, I find, one can develop as worthwhile lecture
or essay by approaching a trite, over-familiar topic from some unusual
angle, and so that's what I did, here.

>   - Viruses, worms, and trojans (VWT) comprise only one threat model for
>     a system.  

See, I made a special point of denying this assertion:  I assert that
they are most fruitfully viewed NOT as threats in themselves, but rather
minor aftereffects of underlying, much-more-important system and
administrative problems.  One should thus attend to the latter, and the
former will then attend to themselves.  Thus, if you are in a position
where you have to worry about malware as a thing in itself, you're
either on a grossly defective OS platform or are screwing up the
fundamentals very badly:

o  Linux worms are (or more likely were[1]) a minor aftereffect of still
   running exposed RH 6.x and earlier (primarily) systems in 2001 without
   any maintenance whatsoever, with kitchen-sink installations, and with
   all of their obsolete, buggy network daemons still running.

   I made this point by going over the eleven Linux worms to date, 
   the essentially brittle nature of their construction, why this
   limited what they could attack, the nature of the target population
   in light of RH deploying RHN in Sept. 2000 and default IP-filtering 
   rulesets in May 2002, and -- despite all -- how extremely low even
   the most extravagant claims for the "successful" worms' penetration
   was in context of an estimated installed base of 10-20 million Linux
   hosts by 2001.

o  Linux viruses are almost entirely a lab-specific curiosity and in 
   practice no threat to anyone (in and of themselves).  Sometimes, 
   they're post-breakin insults planted by a root-wielding intruder at 
   the same time he installs his rootkit, in order to keep a UDP-based 
   backdoor available to him in case the admin wakes up and starts 
   changing passwords.

   I made this point by listing all known ELF infectors, explaining how
   they work, and explaining how and why they're often "found" on a host
   root-compromised by other means entirely.

o  Linux trojans are a minor aftereffect of being willing to install and
   run software from untrustworthy sources.

   I made this point by discussing the specifics of the monkey.org, 
   irssi.org, and ftp.win.tue.nl site compromises and trojaning of
   certain source packages hosted there, and why the people NOT taken in 
   were those like Andrew Brown who remembered that in downloading
   source directly from upsteam they were assuming all the obligations
   of a package maintainer including verifying author GPG signatures of
   the alleged release.  I pointed out the lesson that good package 
   maintainers in one's distribution do this check for you and serve 
   as a valuable quality-control checkpoint that should never be 
   bypassed without a really compelling reason and extreme caution.

   I contrasted those three site compromises with the late-2003 site
   compromises of Debian Project and Gentoo Project hosts via stolen 
   login credentials and escalation via the then-new brk() kernel bug 
   and the kernel.bkbits.net compromise -- in which the hosted 
   software distribution chain was NOT compromised because of 
   integrity checking.

The point was not (of course) to allege that proper system
administration regimes are foolproof, but rather to show where 100% of
the people bit in those cases (trojans, worms) were going outside such
regimes and doing reckless things without compensating precautions (a la
Andrew Brown remembering to check the GPG signature and suddenly
realising it was suspiciously missing from tcp-wrappers-7.6.tar.gz).

Ditto, naturally, not properly verifying MD5SUMs on CD images from a
trustworthily GPG-signed MD5SUM claim, etc.

[1] It seems to take a couple of months after discovery of a daemon
vulnerability to craft and set loose an automated worm attack to exploit
it.  Usually, Linux daemon vulnerabilities aren't even known to be
exploitable at _all_ at the time they're discovered and patches start
being passed around and propagating:  Almost all Linux patches are
anticipatory rather than reactive against an already-known exploitable
hole, let alone an already-known _remotely_ exploitable one.

The last Linux worms with any even halfway reasonable prospects of
propagation were in 2002.  (There was a June 2003 one against a buggy 
Samba package, but it was for obvious reasons a non-starter.)  I think
the absence of any more is no accident and relates directly to the RHN
and IP-filtering changes a/o 9/2000 and 5/2002, respectively:  The
target population of (primarily) pre RH7 boxes simply disappeared.

The claims were:  

1i0n and lpdworm:  "thousands"  (2001, Linux population 10-20 million)
Slapper:  3,500 Symantec, 20,000 DiDio (2002, Linux pop. 20-30 million)

Since Sept. 2002, we've had basically nothing.  My guess is that that
window's pretty much closed.  (Of course, someone could still suddenly
unleash a previously completely unknown exploit against OpenSSL or one
of the common kernel TCP/IP stacks using a worm attack and get 1/2 hour
Internet penetration like SQL Slammer, but that seems unlikely.)

More information about the conspire mailing list