Re: update only file system

From: Michael (leahcim@ntlworld.invalid)
Date: 12/09/02 

From: Michael <leahcim@ntlworld.invalid>
Date: Mon, 09 Dec 2002 18:31:49 +0000

On Monday 09 Dec 2002 16:26, Dave Thornburgh
(dave-thorn@nodash.adelphia.net) wrote:

> If you cannot target your intended victim, since it has no address,
> then it has less chance of being vulnerable to attacks against the
> logging daemon.

Yes, but it is listening just in a different way. In fact it's listening
to potentially _more_ packets than a standard "listen on one UDP port"
program on a single ip would be.

A bug in the log daemon is most likely still exploitable.

Further, you're doing more processing to get at the data (processing
that's normally done by the kernel - and there are millions testing the
kernel's paths) you've more chance of adding a bug.

If the attacker sends a ton of crud on the wire you might crash, possibly
in an exploitable way (same as any code, but more code == more
complexity == more chance of bugs)

>> If anything, things that pick up every packet (tcpdump, IDS systems, a
>> magic log listener etc) have an increased security risk.
>
> Just curious - what did you mean by this last? I'm about to deploy
> some stealth-running IDS systems (snort), and am wondering if I
> overlooked something obvious.

Well, if you're listening to every packet on the wire, you're pulling in
traffic that was and wasn't destined for the machine. More packets ==
more chance of grabbing something to trip you up.

In the IDS case, you may also be processing the data in a way that's
trying to keep track of a very complex piece of software - the network
stack and perhaps analysing several tcp/udp protocols as well - and
handling whatever other random junk that might get thrown at it.

Hence there's a chance of data which would otherwise harmlessly have been
processed by the kernel, being an exploit for a promisc listener.

Ironically, one of the things about IDS is the reverse, it not being
exploitable by data that might exploit the real destination.

Pragmatically of course, in the real world something's either buggy or
not and the log daemon, web server etc might be buggy, the IDS not.

So I'm not saying anything specific about snort, that seems to have
plenty of analysis and users using it - don't let my comments put you
off :o)

But logging daemons don't seem to cry out for an in-depth knowledge of
what's on the wire - I guess I'm saying I don't think extending them to
need some of that knowledge will help.

Given a stable log daemon, that's run on millions of systems and adding
some promisc listener stuff on the front doesn't seem to give you
anything yet it is increasing code and increasing complexity, which
doesn't immediately suggest improving security. 

-- 
Michael.

Relevant Pages

  • Re: SETI
    ... SCIENTISTS to think there is even a remote chance that another ... civilization is out there within hailing distance is disheartening. ... listening or trying to communicate. ...
    (talk.origins)
  • Re: Is this the shittest, most overrated music ever?
    ... I'd say your insight into my music tastes is spot ... Society had one chance, one fleeting opportunity, to put a well-deserved ... 'full stop' at the end of pop music and start listening to something else ... Did Doves ever get hyped bigly, ...
    (uk.sport.football)
  • Re: hd radio
    ... scribeth thus ... As chance would have it, I'm 'listening again' to the Last Night of the ... Yes theres definitely differences twixt the radio and TV version for a ...
    (uk.rec.audio)
  • Re: Ping JC
    ... Finally had a chance to take a serious listen to the Herbie Nichols ... (With a great booklet included.) ... Can't stop listening to him. ...
    (alt.sports.basketball.nba.la-lakers)
  • Re: what if the message-ID generator generates a dirty word?
    ... considering that the flaw is imaginary in practice? ... so there was only about 1/8th of a chance you'd ... Any site that generates enough IDs is likely to eventually create ... Try searching for 'sexy' in your store of IDs, ...
    (comp.security.misc)