[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ITS#1998, zero-length attr vals



On Tue, Aug 06, 2002 at 10:59:28AM +0200, Stig Venaas wrote:
> > 
> > I don't think that's an issue. As the comment in UTF8StringNormalize
> > states, all whitespace is ASCII; there are no 8-bit or larger
> > characters that fall into the "Space" class, and longer encodings
> > of ASCII characters are illegal. So, the result of the decomposition
> > and mapping should not result in any more spaces than the original
> > string contained.
> 
> We should do mapping first anyway, and even if there are no spaces
> outside ascii, someone might some time change mapping tables so
> that there is. And by doing mapping first, we can simply check for
> U+0020 and nothing else later.

Don't forget that someone might deliberately encode some
character in more bytes than are necessary in order to attack the
server by breaking the normalisation. This was the basis for one of
the big attacks on the IIS webserver, which is still on the SANS
Top-20 Internet security problems list.

Procedures in libraries/libldap/utf-8.c appear to block over-length
encodings, but there is a comment in libraries/libldap/utf-8-conv.c
that says:


	This code does not prevent UTF-8 sequences which are longer than
	necessary from being decoded.

In spite of that, they do seem to protect themselves by calling
LDAP_UTF8_CHARLEN2 and checking for zero returns.

What I cannot quickly work out is whether UTF8StringNormalize (in
servers/slapd/schema_init.c) is only called on strings that have been
sanitised by one of the library procedures. If not, then there is
potential for trouble.

Andrew
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|        Andrew.Findlay@skills-1st.co.uk       +44 1628 782565        |
-----------------------------------------------------------------------