NX Security (was [FreeNX-kNX] Re: got: "cannot create directory `/home/.nx'")

freenx at mikebell.org freenx at mikebell.org
Wed Oct 20 04:01:30 UTC 2004


On Wed, Oct 20, 2004 at 04:17:16AM +0200, Kurt Pfeifle wrote:
> If you use an encrypted one, everything goes through Port 22 (or which
> ever you chose to let your sshd listen at). Note, that it is always the
> system's builtin and configured sshd which NX and NX clients contact 
> for connection. Note, that this sshd may or may not be configured to
> allow port forwarding for any logged in user -- be there NX installed 
> or be there NX banned from it.

So in other words, you don't know how it works? :)


> > Finally, I'd like to point out that while that news post you pointed out
> > does say the problem with ssh forwarding has been fixed as of about 2
> > months ago, that necessarily implies that everyone running the software
> > BEFORE that point was open to be used as an anonymous relay for any TCP
> > traffic someone with their host key might desire.
> 
> Please stop this now. 
> 
> What you now turn to is mere uninformed trolling. 

> When you say that the previously quoted NX release notes "necessarily 
> imply" that "the host key" allowed "everyone" to use an NX server as
> an anonymous relay for "any TCP traffic" then this is an outright lie,
> and you are the liar. I'll retract that statement only after you have
> proofed me how "everyone" could, under the previous NX versions, abuse
> a publically accessible NX server as such a relay, with just the "nx"
> key and no real user NX account at his disposal.

ssh -L 4000:victimip:victimport nx at publiclyavailableserver

Now send your traffic to port 4000 on localhost. When you connect, sshd
on the remote end will connect to victimip:victimport on your behalf. 
Any data you send will be sent by sshd on your behalf.

This is a DOCUMENTED FACT of sshd. It apples no matter what your shell
is. Even setting shell to /bin/false does not eliminate the problem, it
merely turns it into a race condition. The only fix is to turn off ssh 
port forwarding for the guest user. Check for yourself if you don't
believe me.

> So you would trust *me* if I came up with a well-written document that
> answered your items blow-for-blow? Bad.
> 
> Who am I that you would trust me and my judgement??

This is actually quite simple, if you listen to what's being said rather
than simply argue against it. As it stands I'm pretty much convinced the
nx user is a bad idea. Thus I'd like to avoid freenx and use nxproxy and
nxagent standalone. However, you tell me freenx is secure, that all my
claims of security flaws are baseless. So I ask you to convince me that
this is the case. If you can do so (it /should/ be possible with a
fraction of the text we've wasted arguing) then of course I would
reevaluate freenx. That doesn't mean I'd trust it, but I'd invest the
time to check.

Since, however, you're completely unable to refute these claims with
something crazy like "facts", I can only assume my analysis (and that of
all the people you claim are spreading "FUD") holds and that I shouldn't
waste my time.

> Again not true. You admittedly haven't installed it on your system
> currently, nor you ever had it. And you are free to keep it that way. 

I admit to not installing freenx. I never said anything about the other
parts of NX. The compression technology itself has a great deal of
merit, it's the attempt at a user management system I object to.

> You know what? NoMachine have, since 18 months, a publically
> accessible "testdrive" NX server exposed to the Internet. They invite
> everyone to get themselves an account there, and they hand it out very
> generously, without asking for your passport or ID or CV. Chances are,
> that you'll get assigned username test9999 soonish, if you apply now.
> So several thousand of different people have accessed this host
> already....

By that logic, the fact that my publically available BIND 4.0 server
(way back in the day) wasn't rooted back before the vulnerabilities in
it were found categorically proves that it was secure the whole time!

And there were IIS boxes on the net, serving the public for much more
than 18 months, back before code red. So clearly code red never existed
at all!

Simply because an exploit exists doesn't mean it will be instantly
exploited. However you can bet that if nx servers with such a flaw
perpetuated, sooner or later someone would take advantage of it.

> And start again asking here, or arguing, *after* you are tainted with
> some atoms of actual NX testruns. Or stay out of here. But in any
> case, stop wasting other people's time.

Run NX. Was very impressed by the performance. But without the
(undocumented) ssh tunneling support it's useless to me. NX is nice, but
no piece of software has unlimited worth, and I've already spent long
enough pouring over source code where the command line parsing is buried
inside the library.



More information about the FreeNX-kNX mailing list