[X2Go-Dev] [X2Go-Commits] [nx-libs] 32/52: dix: integer overflow in GetHosts() [CVE-2014-8092 2/4]

[Mihai Moldovan]

On 14.02.2015 05:47 PM, git-admin at x2go.org wrote:
> This is an automated email from the git hooks/post-receive script.
>
> x2go pushed a commit to branch 3.6.x
> in repository nx-libs.
>
> commit d4c76981f7fddb364166464c571ed8d3de3086cd
> Author: Alan Coopersmith <alan.coopersmith at oracle.com>
> Date:   Mon Jan 6 23:30:14 2014 -0800
>
>     dix: integer overflow in GetHosts() [CVE-2014-8092 2/4]
>     
>     GetHosts() iterates over all the hosts it has in memory, and copies
>     them to a buffer. The buffer length is calculated by iterating over
>     all the hosts and adding up all of their combined length. There is a
>     potential integer overflow, if there are lots and lots of hosts (with
>     a combined length of > ~4 gig). This should be possible by repeatedly
>     calling ProcChangeHosts() on 64bit machines with enough memory.
>     
>     This patch caps the list at 1mb, because multi-megabyte hostname
>     lists for X access control are insane.
>     
>     v2: backport to nx-libs 3.6.x (Mike DePaulo)
>     Reported-by: Ilja Van Sprundel <ivansprundel at ioactive.com>
>     Signed-off-by: Alan Coopersmith <alan.coopersmith at oracle.com>
>     Reviewed-by: Peter Hutterer <peter.hutterer at who-t.net>
>     
>     Conflicts:
>     	os/access.c
> ---
>  nx-X11/programs/Xserver/os/access.c |    6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/nx-X11/programs/Xserver/os/access.c b/nx-X11/programs/Xserver/os/access.c
> index b6a70a7..0e9d138 100644
> --- a/nx-X11/programs/Xserver/os/access.c
> +++ b/nx-X11/programs/Xserver/os/access.c
> @@ -1719,6 +1719,10 @@ GetHosts (
>      {
>  	nHosts++;
>  	n += (((host->len + 3) >> 2) << 2) + sizeof(xHostEntry);
> +        /* Could check for INT_MAX, but in reality having more than 1mb of
> +           hostnames in the access list is ridiculous */
> +        if (n >= 1048576)

Not an error: I'd change the number "1048576" to "1024*1024", because
"1048576" is not easily recognized as 1 MB while the latter is more
clear (and the compiler statically optimizes it at compile/preprocessing
time anyway.)

if (n >= 1024*1024)



Everything else looks fine.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <http://lists.x2go.org/pipermail/x2go-dev/attachments/20150215/78d2fb88/attachment.pgp>