Re: [logs] Syslog payload format

avalonat_private

In some mail from Kyle R. Hofmann, sie said:
> 
> On Thu, 19 Dec 2002 13:32:20 -0500, "Marcus J. Ranum" wrote:
> > >Maybe this is good, maybe it's bad, but it gets away from
> > >varargs and is hopefully clear about relationship between type and
> > >object data.
> > 
> > Typing log data's a problem I think it's best to ignore.
> > Systems aren't going to always have the best information
> > and if they can't type it right we need to give them a
> > chance to send something else - whatever they have. Which
> > means that a lot of this stuff is going to get promoted
> > to strings eventually.
> 
> No, I think the logical outcome of that is that everything is made binary.
> I'm sure we can all recall exploits where a sure-fire way of discovering if
> you'd been attacked was whether or not you saw a particular string of binary
> garbage (the payload) in your log.  We need to account for the possibility
> that log data will have \0's liberally inserted.

I'm with you on this.  I suppose it makes ASN.1 seem more likely and
perhaps harder to resist if faced with it, but how many buffer overflows,
etc, are because of problems with string handling ?  Unless we are all
using a "safe" language like Java, where you'd just write serialise
methods for the log objects, it just seems like we're asking for trouble.

I suppose there have been similar problems with ASN.1 and SNMP so if
we were to avoid strings on the grounds of security, so too we should
try and avoid ASN.1 (which is less than trivial to parse or generate.)

> So we want an interface more like:
> 
> event_new(&evt);
> event_tag(&evt, "TAG", data, data_length);
> event_send(&evt);
> event_del(&evt);

And make "evt" be a "void *" ? >:)

> For just a plain string I think you'll see people do add_tag(&evt, "TAG",
> string, strlen(string));.  That should be discouraged, especially if
> string is somehow derived from user input.

Why ?  Maybe it is necssary to return a value from event_tag() and
have it "fail" if the "TAG" arg contains bad data ?

Where I was coming from with building up an array of things was it is
not a big deal to change one element if you are doing something like
emitting a log record per iteration when walking through a list or
an array.  I do take Marcus's comment about exposing internal data
types though.

> I think the four things that I've listed there are the minimum, unless we
> want to use a single variadic function call (which strikes me as inelegant
> and perhaps not portable to languages not derived from or related to C,
> especially strongly-typed languages).  Of course we need other functions for
> convienience and speed, but does anyone have any better proposals for a
> minimum workable set of functions?  Also, what other helper functions do we
> need?

On the topic of helped functions, an analogue to openlog() is one.

Something I would like to remind people about, here, is that the
transmission of data may not look anything like the storing of it
in log files.  Both have completely different purposes so there
should be no reason to make their content the same (?).  Hence the
protocol data need not be "grep'able".

Darren
_______________________________________________
LogAnalysis mailing list
LogAnalysisat_private
http://lists.shmoo.com/mailman/listinfo/loganalysis