[conspire] linux antivirus?

Ryan Russell ryan at thievco.com
Thu Sep 11 20:19:31 PDT 2003

Rick Moen wrote:

> And then you turn it off.  Or add a line to /etc/hosts.deny.  

Same with Windows users.  They're not using RPCDCOM, just turn it off.  Why
didn't they?   They didn't know, they didn't care.  How is it different?
Oh look, they all got nailed, and it's STILL not off.  It's just patched...
and whoops, there's like 4 new vulnerabilities in it as of yesterday.
Guess they never learn.

>>It demonstrates my point that, yes, dumb Linux users/admins do exist.
> Let's be really clear about this:  If you run a bunch of network
> daemons, leave them exposed to the Internet, and ignore security
> advisories and urgently recommended updates for five-plus months, your
> system _will_ get root-compromised.  But:

We agree then, it will be compromised.  Do you agree that people really,
truly do that?  They really leaves boxes unpatched for that long?  And that
when they get compromised, maybe it was a worm that did it?

> The most-important point:  This would happen with or without the
> existence of malware.  Remember, the "worms" you wrote about were merely
> ways of 'sploiting larger numbers of netblocks more quickly.

So what?  The Windows boxes would get compromised the same way, how is this
different?  Did, in fact, the malicious code get on using an exploit?

>>So why didn't they patch them?
> Irrelevant.  The point is that they basically nullified their own system
> security.  

Yes, that's the point I'm making... clueless users nullify their own
security.  You agree then?  it doesn't matter whether they nullify their
own security because of failing to patch, or running as root, or clicking
on the dancing pig program?  The basic problem is that there's a clueless
user at the helm, so they will get compromised?

> Calling that a malware problem is missing the point.

Ah, now we're getting somewhere.  Yes, that overall problem is a SUPERSET
of problems, which includes getting infected with malicious code.  Agree?
You screw up your box admin, one of the things you will end up with is
worms?  (Minus that few that had the good fortune to have someone else move
in and start administering the box, fo course.)

So, I agree that it's not JUST and malicious code problem.  I do, however,
claim that this situation is one that will also enable/help/allow malicious

> Please note that Red Hat, Inc., with its complimentary one-machine
> subscription to RHN, has of late made it extremely difficult for even
> grossly incompetent admins to screw up that way.  Now, it's difficult to
> _avoid_ getting security updates.  (That's not to mention the default
> netfilter script introduced after RH 7.3.)

And the world will build better idiots.  (Incidentally, I'm a fan of
up2date, I just wish it were a bit more free... can't fault them, though.
Must be expensive to maintain the infrastructure.)  Give them all the tools
you want, and some people will still manage to ignore them.  Up2date is
very much on par with windowsupdate.microsoft.com, yet MILLIONS of Windows
users can't be bothered to visit a web page, or install the reminder tool.
  All they have to do is click "yes" about twice... they can't be bothered.

> See above:  Their failure to protect their own asses helped _exploits_

So do you agree that they failed, and that they got exploited?

> against their machines, in the same way that leaving all your doors and
> windows open with jerrycans of gasoline piled against your doorstep
> would help arsonists.  Those exploits were a dead-certainty with or
> without the malware.  The latter was merely _automation_ of the 'sploits.

Sure.  And did they actually end up with malicious code on their boxes?

> The malware thus added nothing to the situation other than causing
> system compromise to happen a bit sooner than otherwise.

Or at all.  Or in addition to.  Could the worm have gotten on if the hole
wasn't there?

The reality is that you can have a hole exist for months, and some small
portion of the boxes will get owned.  Then a worm with the same exploit
comes along, and all those boxes (unless someone took care to disable the
hole) have the worm, plus a huge number of other boxes.  Example: rpcdcom
hole.  Exploits abounded for a couple weeks, and probably thousands of
boxes were 0wned.  The worm (Blaster) comes out, and hundreds of thousands
of boxes are now infected.  You can also call that 0wned, or not, doesn't
matter.  They've got worm, though.

>>Yes, that would be my definition of "root service", a network service 
>>running as root...So the shellcode was running as root.  Sorry if my 
>>terminology wasn't clear.

> That's not "popping a root service" in any meaningful sense:  That's
> just a garden-variety buffer overflow without privilege escalation.  Not
> clever, not surprising -- and nothing really to do with malware.

"Popping a root service" (colloquially) is defined in all the circles I run
in as exploiting a process running as root in order to perform some
unintended action with root privileges.  If you don't like that definition,
that's your perogative.  It may or may not have been done with a buffer
overflow. You can call it a priv escalation or not; many of the people I
know consider it to be escalating from nopriv/noshell (generic outside
unauthenticated network user) to root user with a shell (assuming your
"shellcode" does, in fact, give you a shell.)

It has everything to do with malicious code, because that's how the worm
gets on the box.  Certainly you can't sanely argue against the fact that
the vast majority of worms exploit a vulnerability in a remote privileged
service in order to copy themselves onto a victim and execute.  If you
don't agree with that, then you've got a vastly different meaning for
"worm" than all the rest of us.  Please share.  What do you call the thing
I describe?  I'm starting to wonder if you're being intentionally obscure
with your definitions.


More information about the conspire mailing list