Re: NGS00099 Patch Notification: Vulnerable SUID script in (nomachine) NX Server for Linux

[Tavis Ormandy <taviso@xxxxxxxxxxxxx>]

Research@NGSSecure <research@xxxxxxxxxxxxx> wrote:

> Vulnerable SUID script in (nomachine) NX Server for Linux 3.5.0-4
> (Advanced and Enterprise across redhat and debian hosts)
> 
> 21 September 2011
> 
> NGS Secure has discovered a High risk vulnerability in (nomachine) NX
> Server for Linux 3.5.0-4 (Advanced and Enterprise across redhat and debian
> hosts).
> 
> Impact: Arbitrary files can be read with root privileges
> 
> The fix was rated critical by the vendor and short term patch was to
> remove the offending script.
> 
> http://www.nomachine.com/tr/view.php?id=TR08I02575
> 
> NGS Secure is going to withhold details of this flaw for three months.
> This three month window will allow users the time needed to apply the
> patch before the details are released to the general public. This reflects
> the NGS Secure approach to responsible disclosure.
> 
> NGS Secure Research http://www.ngssecure.com
> 
> 
> 
> 

I guess I probably wasn't the only person confused by your advisory, you
described a setuid script, but didn't explain how that's possible. I don't
know if you were being intentionally secretive, but I looked into it.

It looks like NX ship a suid wrapper called nxuexec that operates in a
similar fashion to suidperl. suidperl had numerous problems over the years
until it was beaten into reasonable shape by researchers, obviously nuexec
has not had that benefit.

$ ls -l /usr/NX/bin/nxuexec
-r-sr-xr-x 1 root root 14K Sep 24  2009 /usr/NX/bin/nxuexec*

I suppose the problem you're referring to is the user-controlled parameter
being passed to bash, allowing you to trivially escape from the quoted
string. I won't provide full details as per your wishes, although I think it
will be obvious to anyone who looks after reading your description.

However, nxuexec is clearly broken by design. The reason it's hard to create
suidroot shell scripts is because if you think that's a good idea, you
probably shouldnt be doing it :-)

They're implementation has numerous problems, the most obvious is failure to
adequately sanitise the environment:

$ env SHELLOPTS=xtrace PS4='$(/usr/bin/id)' /usr/NX/bin/nxuexec nxdpyinfo.sh
uid=0(root)

(This xtrace trick is an old technique to bypass the blacklisting used by
sudo a few years ago, of course it uses whitelisting now)

I'm sure there are far more problems, I would suggest creating a new group,
e.g. nxtrusted, then something like this:

# chgrp nxtrusted /usr/NX/bin/nxuexec
# chmod 4750 /usr/NX/bin/nxuexec

Now you can add the users you trust to this group.

Tavis.

-- 
-------------------------------------
taviso@xxxxxxxxxxxxx | pgp encrypted mail preferred
-------------------------------------------------------