2016-10-10 20:39:08

the key hook is a bug in nvda, not in nvda remote as previously stated. And how would you suppose to code a hidden file where key info is stored if the addon is opensource?

Roel
golfing in the kitchen

2016-10-10 20:46:30

no no rol, the key hook is not a bug in nvda. The bug in nvda is that long strings crash the program. The keyhook takes our keyboard input and sends it to remote clients. That's not in NVDA. That is in remote. When NVDA was crashed, it was impossible to disable the keyhook that was remote generated.

I am a web designer, and a game developer. If you wish see me at http://www.samtupy.com

2016-10-10 20:54:07

My point still stands: you need to press f11 to disable the keyhook that remote starts by using events from nvda. Because nvda crashes, the keyhook can't be disabled, so that is still something that needs to be fixed in nvda, not remote. And if you want to do encryption on the file, the only slightly safer way to do it is to use an executable that handles the encryption which goes against the gpl and which could hide malicious code itself. Really, if someone has access to your nvda remote key, you need to ask yourself to what other info that person has read/write access. He will have write access to your startup programs as well, so he could just make a script which does that instead. What you're basically saying whith your key insecurity is: I ran a script from someone, that enabled windows remote desktop or whatever, and rdp is vulnerable because it allowed itself to be enabled by a malicious script that I ran myself. This just doesn't make sence at all.

Roel
golfing in the kitchen

2016-10-10 20:54:58 (edited by stargate 2016-10-10 20:59:15)

Replying to 49. SO why didn't you write something up? You want the NVDA Remote developers to code something that cannot be easily done, yet you refuse to contribute. How do you propose they fix it with the entire project being open source? Create a false sense of security?

With that out of the way, I see what you're saying about the keyhook Sam. That doesn't negate the fact that if you had been using NVDA Remote for its intended purpose, none of this would have happened. It also doesn't change the fact that the problem lies with NVDA. If NVDA hadn't crashed when seeing a long string, the keyhook wouldn't be causing a problem. It seems that you're still not willing to admit that connecting to a shared key may not have been a very smart idea. I think I know what you're going to say as a response. "But I didn't click allow control." Once again, you wouldn't have needed to allow control. Remote needs to speak what is sent from the controlling machine, and Tyler used that to invoke the NVDA bug. That's a risk all of you took when you connected to a publicly posted key.

2016-10-10 20:56:15

I even talked to Tyler about this. Look at ssh. The average user most likely doesn't generate key pairs, but the more advanced user who is paranoid about security would. So add something. A checkbox, whatever. THat's on remote.ini. but to be honest, I can accept that. The biggest thing is in the way that he actually took time and added the crash clients option to remote. And on twitter, he said the following.

First, @samtupy1 gave his key outpublically. Second, he had no secondary account to restart NVDA. NVDA 101. We're done here.

Now, I'm not at all trying to bash him for everything, no way. And I truly understand that some just won't agree, and I will accept that. But honestly, how would a second user account be required? Where does it say this? Am I required to expect this to happen? I did not sign up to get hacked on my main computer, it was Ivan who did that.

2016-10-10 20:57:21

A few things here.
I agree what Tyler did was a dick move, however...
Here's a metaphorical situation. Ready?
Let me give you a key to my house. You can walk on in, grab my laptop and a few externals before I could blink and knock me flying before running out.
Essentially (or maybe not essentially, since Mason just said you didn't lose data) this is what happened. You quite literally brought this on yourselves. As amusing as the recording is (yes, I'm sorry, it was amusing), relax. I've actually seen this bug in NVDA (having nothing to do with remote whatsoever, I've crashed local machines).
Here's hoping it will be fixed. One thing I'd also love to see is an NVDA remote server made publicly available (already compiled and ready for use). One of the nicest things is that you can step away from the nvdaremote.com if you truly wanted to if you know how to compile the source for the server. I myself haven't had any problems with it, though, and it's sad that the developer of this thing got himself involved in this. Not going to make a few people trust him or want to work with him though at the same time, it should teach some folks a lesson about how not to be a complete and utter idiot, and I'm sure he can be forgiven just a little. I certainly haven't had a problem with him with what little interaction I've had and all of this seems so completely overblown and attention grabbing.
Wolf out for now. Please relax bros.

Something something something insert canine related comment here

2016-10-10 21:06:39

I think the reason Q told you off when asked about hiding the ini is because, it, just, can't, happen. Even if it's hidden, the sourcecode is still present, and anyone can go figure out how it's hidden. Even if key handling was done entirely via the server, people could still find the lines in the code that direct the client to look up the information, encrypted or otherwise, and change it up to, say, grab that key and store it as a n decrypted text file in appdata. There's simply no way, and it's why businesses tend to turn a blind eye to open source software, for this very reason. Security is about as good as the knowledge of the person behind the machine. For example, I'd have not one shred of sympathy for someone who got hacked who was using sissy 8character or less, repetitive passwords, or stored their passwords in a raw text file. That's their own fault, they subjected themselves to vulnerability. That's the same with Nvda remote. While I understand what Tyler did wasn't exactly right, Ivan isn't entirely blameless in this situation either. Sure, the remote eventually disconnected, but the thing is the key's already out there, on the nvdaremote.com server no less. If that's not subjecting yourself to vulnerability I don't know what is. So if the key was never passed around, it's not nearly as likely this would've happened. Also, yes, you should definitely be saving your work at least every 5 minutes or so. It's as easy as one command, or program your own script to autosave. Damien from x-sight did that once. Not trying to defend what Tyler did, mind you it was still a pretty drastic way to teach a lesson, but just a general reminder to save often. And don't think for a second that Nvda Remote is singled out in this matter just because it's open sourced. Yes, it may be one of the few times where one of the devs actually did something like this, but shit goes down on Microsoft Remote Desktop/Teamviewer too, both closed source, in deed probably even less secure depending on how you use it since you're putting your trust in a company that you have no control over. Sure, Microsoft has a clause in their terms of service clearly warning users of getting banned if caught hacking computers with remote desktop, but what do you know? How do you know that Microsoft doesn't log packets? Nvda remote could be on the central server as well. Hell, if you're paranoid, just run your own server. I'm sure if you have this great and superior solution to running off the central server, you have enough money to pay the reasonable price for a server.

2016-10-10 21:21:12

@54:
You miss understood my message. Because it is impossible to hide a secret key in opensource software, it is impossible to implement such a thing by q or anyone else. It was ment to make you think about how you would do that, not as a bash on q or any other nvda remote contributor for not implementing such a feature.

Roel
golfing in the kitchen

2016-10-10 21:35:58

Hi. I thought I already said that it is my fault for connecting to a public key. If I didn't write that earlier like I thought I did (i'll check posts), I ment to. I could see how doing something like that could be stupid. And againi, if it wasn't the developer of the addon him self doing this, We wouldn't even be having this conversation right now. I think what's going on is I feel mis understood, and a lot of you guys feel like all that were trying to do is grab attention. It is true that we do want everyone to know what happened, but this isn't happening to make a scene. It's happening so that everything can be made streight. So far I think it's kind of been back forth yes no, but that's not how it's meant to be or how I intended this to be. And also, getting mad at RDP for a script that I ran opening it... Ok, here is the difference. This time the script was pretty much written by the developer him self. He even posted saying we were idiots for trying to hack ivan, so he was defenatly trying not to mess with him. Lets use another sort of metiforical example. Though this time, still having to do with computers. It's like knowiong a flaw in windows, right? A flaw that if done, maybe you delete this thing, or send this string threw the network card, or something stupid that lets just say makes your screen go black. If I find a way to remotely execute this flaw, are you going to blame me, or the windows flaw. I can say maybe I am going a bit to hard on remote and maybe I should direct this more at tyler, it's just so insane that the dev of the remote software used that exact software to harm people. I find it very hard to understand your point of view. Just like mine doesn't make sence to you probably very clearly, yours doesn't very clearly. I personally take it as saying, if you run a batch file that calls the windows format function, instead of blaming the batch file you ran and the person who created it, you blame the format function for existing in the first place. That's how i'm picking up your point of view.

I am a web designer, and a game developer. If you wish see me at http://www.samtupy.com

2016-10-10 22:11:07 (edited by stargate 2016-10-10 22:22:03)

I actually like the way this topic is going. I thought in the beginning that it would turn into a heated debate, but it's been perfectly civil. I do see where you're coming from Sam, and I get the issue that you're trying to point out. I think the blame lies much more on Tyler than it does NVDA Remote or NVDA. I'm glad Toth took the stance he did and looked into what can be done to resolve this problem, either on NVDA's side or Remote. If nothing else, maybe the issue with NVDA will be resolved or a patch will be put in Remote to avoid a similar situation in the future. I hope that there won't be a similar situation in the future though, and that nobody shares any more keys publicly. Nothing good can come of that.

I do feel the topic title is a bit misleading though, and that is what I meant when I said that you were trying to attract attention to a problem that isn't as  big of a deal as you made it out to be. When I see the title, I think of a security flaw. Something that would give someone unauthorized access to my computer, but that's not what happened.

2016-10-11 01:15:36

Sam, I get what you mean. Hopefully the NVDA devs can fix the bug that allows the f11 hook to die, at least. Or perhaps NVDA remote could query NVDA's activity closely, and if the main program doesn't respond properly, within maybe 2 or so seconds to account for lag, program unresponsiveness, stuff like that, then  maybe NVDA remote could automatically die.

Devin Prater
My Blog
Follow me

2016-10-11 04:12:58

So I'm going to write this and try to get everything down.
First, everything sam's throwing around about setting a unix processor timestamp to -1 and csrs.exe being killed is utterly pointless. So please disregard all of the analogies and people throwing around words like they're in the know here.

I want to run down the events as I understand them to try to clear things up, which I think other calmer heads have been doing.
1) Ivan posted a link on twitter saying almost quite literally "my key is 123, come fuck with me."
2) Around 10 or so people connected to the server as a controler. Ivan disconnected as a controlee and Tyler Spivy connected.
3) Tyler Spivy connected with a vm and allowed himself to be controled. He sent long strings of text to the clients which crashed them.

There are two bugs that resulted from this, one is not so much a bug.
1) When you send long strings of text, an error box shows up and allows you to click okay before the synth can keep running again.
2) If the user is stuck in this dialog and is also controling another system (in this case Tyler Spivy's vm), NVDA will not process input until that dialog is dismissed. Thus this requires a hard reboot or potentially someone with a mouse to click okay and dismiss the dialog.

Personal musings:
Firstly, I think there are a lot of things to learn from this encounter. The most common might be that if you tell people to come screw with you, chances are they're going to do so. Does that mean that Tyler should have done what he did? Certainly not. It is worth note though, if you decide to go through the trauma of listening to that Teamtalk recording, Sam and his friends were excited at first. They wanted the "crash clients" option and wanted to examine the code. When things became a problem is when the tables were turned and their machines were locked up.
2) Sam and his friends lost their homework and code simply because they did not save and had to hard reboot. Whether it was Spivy or a power outage or anything else, that would have done the same.

These issues and my comments on Twitter highlight an issue with NVDA remote. Firstly, there was more than $15000 donated to make this thing work. In an inspection of the code (I'll explain why shortly), I noticed a distinct lack of much error checking or any sanitation which may be a problem and I know can be when things don't work. There are a lot of cases where when an error is encountered in the code, Remote just exits and drops everything on the floor. These issues are pretty big and although it is an open source project, these initial developers were paid $15000 and should probably be keeping this up. This isn't any different from the attitude taken with most of Q's software; he grabs up the money, gets a mediocre product out and then calls it a day, refusing to offer much, if any support. Basically the fact that this is open source means that someone else needs to clean up the mess after the initial authors were already paid half a yearly salary for many people.

I would also like to explain some of the prior interactions because they were mentioned in some of this mess. About 4-5 months ago, Sam contacted Q on Twitter with the same kind of attitude and analogies, mentioning that he felt he is being hacked. I and Q spent time trying to figure out what the issue was; Sam was leaving NVDA remote enabled on his windows server where STW was running and his various other games and someone was supposedly guessing his key. This was never solved and I can't really tell through looking at the code if this was possible without diving deeper and trying to actually break things.
Hopefully some of this helped.

2016-10-11 05:31:17 (edited by Slender 2016-10-11 05:58:07)

As I put it on Twitter, this whole situation feels like a bunch of FUD (fear, uncertainty and doubt). This happened with the remote.ini flaw, now it's this. When TW Blue had a security issue that could result in your user token getting stolen by an attacker, effectively allowing people to impersonate you on Twitter, no one even reacted or came to the forum to warn people (this issue was fixed in an update). However when a rather insignificant flaw like this one which started basically because people gave out their keys, they come here and tell everybody NVDA remote is the most insecure addon you could ever have installed. Now if they never gave out the key and Tyler just burst in and crashed them in the middle of a remote session, I would understand their anger, But no, from what I've been hearing, that absolutely didn't happen. Takeaway: if you are just the average guy trying to help your parents set up their computers, use strong keys, or use the generate key button, disconnect when your done, or perhaps host your own server if you want to autoconnect, and you'll be just fine.

Oh no! Somebody released the h key! Everybody run and hide!

2016-10-11 10:30:32

*reads all 63 posts and facepalms*

2016-10-11 15:27:38

I didn't read more than one in its entirety and decided it wasn't worth my time.  Honestly, common sense really is necessary when dealing with any piece of software... Period.

When life gives you oranges, demand lemons since everyone else is obviously getting them.

2016-10-13 01:34:34

Well, as I don't know the Teamtalk server from where you were in the discussion that's so embarasing to me. If that happens again I will never use remote.

73 Wj3u

2016-10-14 19:04:37

Play stupid games, win stupid prizes. Need I say more? What's happening to the human race?

Grab my Adventure at C: stages Right here.

2016-10-15 02:18:47

You said it, Chris.

2016-10-16 16:57:29

Ah, I can always rely on this forum to provide me with some sort of blindy drama... Thanks Guys.

To see a world in a grain of sand, and a heaven in a wild flower.
Hold infinity in the palm of your hand, and eternity in an hour.
William Blake - Auguries of Innocence, line 1 to 4

2016-10-16 19:35:12

So I just skimmed a bit. Are people giving out their passwords, then blaming the platform when the people they gave the passwords to aren't trustworthy after all? I sorta feel like I've seen this on other fronts of this drama that I've been unable to avoid, not just NVDA remote. But maybe I'm misremembering.

So, uh, maybe we should keep private security information private from now on? Set up groups that require multiple people have access so that they don't put anything important at risk?

看過來!
"If you want utopia but reality gives you Lovecraft, you don't give up, you carve your utopia out of the corpses of dead gods."
MaxAngor wrote:
    George... Don't do that.

2016-10-16 19:54:27

That's the general idea, yes.  We open the door and we let in the thieves and the house is bad.

When life gives you oranges, demand lemons since everyone else is obviously getting them.

2016-10-16 19:56:46

Basically what happened is Ivan basically broadcasted his nvda remote key to the world, that's what started this whole thing. Whether Ivan disconnected in the midst of this or not, it doesn't matter. You just, don't, give, out, your, password, plain and simple. Nvda Remote has no terms of service, but do you honestly think that Microsoft, for example, would've stayed mute if someone had done that one Remote Desktop? No, in fact if any twerp were to do that they would've at the very least gotten a polite reminder not to. Yes, Tyler's lesson was a little harsh and, not entirely right, it was a lesson after all. And, for the last time, don't be your own vulnerability with passwords, ok? Just don't. 123, even if your intention was to broadcast your remote password out to the world, is about the least amount of effort you could put into a password, and normally, while I wouldn't actually be the one doing this, I wouldn't have one shred of sympathy if someone with a poor excuse for a password got hacked. Tie this to the unnecessary drama, and you've got a volatile  mixture. *sigh*

2016-10-18 00:59:11 (edited by Dan Gero 2016-10-18 03:04:44)

I would like to point out to anyone who may have missed it that Ivan said, and I quote,

if you want to fuck me over, connect to this key, 123.

He specifically instructed people to fuck him over, and Tiler seemingly did so. Why is it wrong? Oh yes, that's right! Because Tiler is the damn developer, that's why! Well, let me make 1 thing quite clear. If you specifically asked people to fuck you over, then there's nothing wrong with what Tiler did. So why are you posting a topic about how NVDA remote is insecure when you asked for it. I would like to refer you to post 67 of this thread.

Chris wrote:

Play stupid games, win stupid prizes. Need I say more? What's happening to the human race?

While I do believe Chris's last statement is going a little overboard, I can agree with the main point. leave your car keys out in the open with a note that says,

hey guys, if you want to fuck me over, take my car keys and rec my car into the nearest brick wall,

and you find your car completely totaled in a Walmart parking lot, don't scream at the person who wrecked it, cause it's your own damn fault.

Discord: dangero#0750
Steam: dangero2000
TWITCH
YOUTUBE and YOUTUBE DISCORD SERVER

2016-10-18 03:59:22

And pay particular attention to the specific request, he did say, "fuck me over," so he asked for it alright.