Re: nss-pam-ldapd commit: r1085 - nss-pam-ldapd/nslcd

[Arthur de Jong <arthur [at] arthurdejong.org>]

On Fri, 2010-05-07 at 22:40 +0200, Commits of the nss-pam-ldapd project. wrote:
> Date: Fri May  7 22:40:13 2010
> New Revision: 1085
> URL: http://arthurdejong.org/viewvc/nss-pam-ldapd?view=rev&revision=1085
> 
> Log:
> fix buffer overflow and implement test for it

Just a heads up in case anyone wonders about this. I have investigated
this buffer overflow and as far as I can determine (I went through all
the code that ends up calling this function) this should not be
exploitable.

The bug allows you to write 5 extra bytes (4 characters and a \0) over
the end of the buffer. You could end up writing 8 extra bytes in case
the last characters would need to be escaped but for most places this
means that the overflow would not work at all. Since most of the buffers
are allocated on the stack this would allow for a stack-based buffer
overflow in the nslcd daemon.

The only place I found where this buffer overflow can be triggered is in
the lookup to find groups a user belongs to (nslcd_group_bymember()
which calls mkfilter_group_bymember()). By generating a request with a
long user name (84 characters) the buffer will overflow. The extra bytes
will flow into another buffer on the stack which is either overwritten
or (more likely) not used. Therefore, it should not be possible to turn
this into an actual attack (neither a crash nor code execution).

The provided user name is checked first to only contain valid characters
for user names (using isvalidname()) so it should only be possible to
overflow the buffer with ASCII characters further limiting the
possibility of exploiting this.

In all other places the value that is passed to the escape function is
sufficiently small as not to be able to overflow the buffer (not even
when all characters need escaping). Values read from incoming requests
are generally limited to 256 bytes, while the escape-buffer is 1024
bytes. Since a 256 bytes value (255 characters and a trailing \0) can at
most expand to 766 bytes due to escaping this should always be safe.

Note that I only reviewed code of the 0.7.3 release. Versions before
0.7.2 should not have the problem in nslcd_group_bymember() as described
above. The buffer overflow itself has been in the software since 2007.

Btw, I found this when testing some new code using valgrind. In that
code malloc()-allocated buffers were used (which valgrind can catch).
Does anyone know of a good tool to find stack-based buffer overflows?

-- 
-- arthur - arthur@arthurdejong.org - http://arthurdejong.org --

--
To unsubscribe send an email to
nss-pam-ldapd-users-unsubscribe@lists.arthurdejong.org or see
http://lists.arthurdejong.org/nss-pam-ldapd-users