Security flaw in RealVNC 4.1.1

intelliadmin.com ^ | Monday, May 08, 2006 | Steve Wiseman

[zeugma]

Security flaw in RealVNC 4.1.1
 

Update #2 (05/11/2006) - We have a proof of concept. You can see if your vulnerable. See our latest post for details

Update (05/08/2006) - We have installed RealVNC 4.1.1 on as many fresh computers as possible. We wanted to make sure this is a real problem - indeed it is. Every single time we were able to access the machine without a valid password. We are still trying to see what is different about our viewer that exposes this flaw.

We are currently developing a new product that would allow users to remotely install VNC, and manage current VNC installations.

Our viewer is totally 100% new code that we created from the VNC spec and not from the open source Real VNC source tree.

I got a big surprise today when I was testing the viewer code: I was able to view the remote machine without the proper password!

It had to be some type of mistake, so I installed Real VNC 4.1.1 on a test machine:



I set the password to a really huge value that I could not have possibly left in our code by accident. Got back on the development machine and clicked connect:



Instantly I had a view of the remote machine!

I started to wonder how widespread this flaw was so I downloaded TightVNC, and UltraVNC. They are immune. Both of them reject my connection right away.

Then I downloaded RealVNC 4.0 and installed it on another fresh test machine. Same thing as Tight and Ultra - I get disconnected right away.

So it looks like a flaw is in the current RealVNC 4.1.1 authentication process. I am not going to give any clues as to what it is until I can figure it out totally, and promptly let the RealVNC team know so they can resolve the issue.

Please note that I have only tested this on the windows versions of the above software.

Posted By: Steve Wiseman on Monday, May 08, 2006

[zeugma]

I hadn't seen this posted before. I know a lot of admins use VNC for remote administration of both Unix and Windows systems. This is a pretty serious flaw.

The link for the proof of concept is here .

I haven't tested this against Unix systems running VNC yet, as I hace none readily available here. If you use use it on Unix/Linux/OSX, you might want to test against it. I'd appreciate any results against same to he posted here, as I am sure others would as well.

This was posted on Slashdot as well.

 

[zeugma]

Tech ping please for those interested.

[mhx]

So they want you to click on a link that will let them connect back to your machine and try to connect to your VNC server? To see if you have the bug?

Hmmmmmm...

[kinoxi]

no, everybody knows osx is immune from worldly flaws, didn't you get the memo? /s

[johnboy]

thank you. thank you, thank you, thank you.

[kalee]

ping

[ShadowAce]

[Egon]

Irk. I use this utility on all of my PCs. Fortunately, I don't open that port to the outside world-- just internal to the network.

[Senator Bedfellow]

The Slapdash article was typical crap, though - what wasn't mentioned was that only RealVNC (and only this specific version of RealVNC) is affected. TightVNC and Ultr@VNC and other versions of RealVNC are not affected at all. Stupid fearmongering by the editors over there, but that's not exactly new ;)

[Senator Bedfellow]

BTW, I have unused moderator points over there that expire this afternoon, so anyone that wants a bump, let me know :)

[N3WBI3]

Real VNC should *always* be set up to use NT authentication otherwise it is unauditable..

[kpp_kpp]

VNC is only safe over SSH

Having a port/machine open for VNC, even w/VCN authentication, is silly.

[zeugma]

My apologies to all from doing a drive-by posting last night, but I thought it was important enough to get out there before I went to bed.

 The Slapdash article was typical crap, though - what wasn't mentioned was that only RealVNC (and only this specific version of RealVNC) is affected. TightVNC and Ultr@VNC and other versions of RealVNC are not affected at all. Stupid fearmongering by the editors over there, but that's not exactly new ;)

Darn good to know, I'm sure for those who might be affected by this. 

[zeugma]

You're welcome. :-)

See senator_bedfellow's comment below about versions affected.
 

[Senator Bedfellow]

I caught it last night myself, and immediately said to myself "Whoa, that's not good", since I use VNC quite a bit. So I started digging a little, and that's when I found that the /. headline and the article summary were quite misleading, or at least far more alarmist than they needed to be. The guy who discovered this bug specifically said he tested it against Ultr@VNC and TightVNC, and was unable to replicate the flaw that apparently only exists in this particular version of RealVNC - well, personally, Ultr@VNC is my flavor of choice, so I guess I'm okay. If I'd seen that in the summary, I wouldn't have wasted five minutes chasing all this down. Damn slashdotters ;)

[zeugma]

Damn slashdotters ;)

Ya, /. is a PITA sometimes, but it is occasionally useful. I actually found my bash prompt in a comment on /. quite a while back...

 :) echo $PS1
\w `if [ $? = 0 ]; then echo :\\); else echo :\\(; fi`

What that will do is make your prompt into a smiley :) if the last command was successful (i.e., $? is 0). If it is anything but 0, you see a frowney :(

Pretty cool and useful IMO.

[Senator Bedfellow]

LOL - very clever. But don't go over there today - today's designated lefty trollfest is a giant thread on this NSA thing ;)

[ShadowAce]

does that line go in the user's .bash_profile?

[zeugma]

works better if you put it in .bashrc, because .bashrc is read by spawned processes. I believe .bash_profile is only read at login. See 'man bash' for more details :-)

 

[zeugma]

BTW: here's what it looks like in my .bashrc. Gotta do weird things because of the way the shell parses stuff.

PS1="\w \`if [ \$? = 0 ]; then echo :\\\); else echo :\\\(; fi\` "