Subject: RE: [Syslog] New direction and proposed charter

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 24 Nov 2005 09:36:06 +0100

Anton: 

> I can see something like this error message:
> 
>  ...MyApp pid123 MALFORMED_INPUT: Bad input received from 
> client: [aaa\u0000]
> 
> The question is does not it need to be escaped for transport 
> or only in display.  I'd personally prefer deferring any kind 
> of escaping until it is really needed, like when displaying 
> binary to the user.  

I agree it can be a valid character. Also note that we (quickly at that
time) went over this topic in the past and agreed that we would need to
support NUL.

My point is a different one. I have begun to look at the draft from the
implementors point of view. Especially from the view of someone who
want's to upgrade an existing syslogd implementation to syslog-protocol.
One goal of such a person would definitely to do it with as less effort
as possible. 

The issue is that many syslogds are written in C/C++. NUL is used as
string terminator. I can back this by testing. If I send NUL characters
embedded inside the message, almost all existing syslogds terminate the
message text at this point. (side-note: I am currently thinking about if
that is a security vulnerability in almost all syslogds).

If you want to upgrade an existing syslogd to support NUL you can do one
of two things:

#1 rewrite your syslogd so that it uses byte-counted
   strings and not the C RTL string functions
#2 replace the NUL with an escape, e.g. \0 or <00>

#1 would obviously be the best choice (also from a security point of
view). I just doubt that many implementors will accept the
(considerable) effort required. I think that most will resort to #2. #2
must be done early, right after message reception (else you already deal
with C-strings). So when it comes to relaying, the orginal message will
not be preserved (side note: it will also not be preserved when writing
to a file). That means that digital signatures (syslog-sign) will be
broken.

While I see this is an implementation issue (not a protocol one), I also
see that allowing NUL will almost ask for this common implementation
"error". It would also render all efforts in regard to syslog-sign
useless.

So I wonder if it wouldn't be wiser to accept that CLR here and disallow
NUL. After all, I can not see a valid use case for it either... (in the
sample you provided it honestly believe the sender should not send a NUL
octet but a "\u0000" string).

Rainer

> 
> Thanks,
> Anton.  
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Andrew Ross
> > Sent: Wednesday, November 23, 2005 6:17 PM
> > To: 'Rainer Gerhards'
> > Cc: [email-masked]
> > Subject: RE: [Syslog] New direction and proposed charter
> > 
> > 
> > >The only tricky issue that remains is the NUL octet. The 
> > more I think 
> > >about it, the more I think the CLR to disallow it is less 
> > evil than to 
> > >make it stay...
> > 
> > I agree that having the CLR for NUL octet exclusion is OK.
> > 
> > Quick question, if someone is sending international data in 
> > UTF-8 format, can there ever be a valid UTF-8 sequence that 
> > includes a NUL octet value? If so, we need to allow NUL 
> > values in the MSG. 
> > 
> > Does anyone on the list know UTF-8 well enough to answer this?
> > 
> > Cheers
> > 
> > Andrew
> > 
> > 
> > _______________________________________________
> > Syslog mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/syslog
> > 
> 

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: Balazs Scheidler <[email-masked]>
Date: Thu, 24 Nov 2005 10:08:48 +0100

> octet but a "\u0000" string).

\u0000 is a NUL octet at least in its canonical encoding. UTF-8 allows
the same character to be encoded in multiple ways, see a description on
the encoding format:

http://www1.tip.nl/~t876506/utf8tbl.html

And I think it would be wise to require the canonical encoding to be
used and treat all other encodings of the same characters as errors.
this is a large can of worms, lot's of security problems arised from
this issue. (see the IIS problems couple of years ago)

-- 
Bazsi