Re: NVDA Remote crash incident: trust and ethics are important just as technology is, never give out passwords publicly, developer responsibilities


 

Well it was all for fun.
Sadly, on some forums there is a group that cries over security in remote.
No data was lost just stuff in ram, and stuff in ram is destroyed all the time.
They didn't save, someone crashed nvda and they had to restart.
Maybe someone should find this group and put criptolocker on their systems with instructions that they need to apologise to the rest of us for being idiots, not do it again, and say if they do they will be removed from lists and blacklisted for ever.
Nothing to bad, but this group pops up every so often, they lay low then pop up.
They will probably do that right now.

On 12/10/2016 2:46 a.m., Jeremy wrote:
As I understand it, the individuals who had their remote sessions
tinkered with had basically invited someone to screw with them. Once it
became clear who the group was who had their sessions played with, or at
least some of those in the group were, the whole thing became kind of
entertaining. While the person who sent the playful strings of text
could maybe have made slightly better choices, those individuals who
received said playful strings were apparently trying to figure out how
it was done, so they could use it on others.

had those individuals being messed with not had their own malicious
intent, as I strongly suspect, I don't think it would have ever come to
this. Either way, you try and screw with someone and every now and then,
someone much more intelligent than you comes along and plays with you a
little. That's the way of things on the internet.


Shaun Everiss wrote:
I read this to joseph.
1. yeah someone gave his public key which is basically giving his
userid and password.
The user got his nvda crashed and lost data in ram, which for some
stupid reason he hadn't even save.
It was all mindless fun and just users mucking round.
Sadly the same user has gone over the fact that the main dev criss is
not responding to feadback and not hiding the public key, etc, etc.
He then decided to post on a public forum complaining about nv remote
in general not being secure.
This same user has done this drama before.
He got what he deserved is all I am saying.

You shouldn't give out your security info.



On 11/10/2016 8:40 a.m., Joseph Lee wrote:
Dear NVDA community:



I give you permission to pass out the following to other community
members:



Dear users of NVDA Remote Support add-on:



On the morning of October 10, 2016, a group of users connected via
nvdaremote.com experienced a general client crash, with the root of the
problem being a series of events that led to NVDA crashing with long
strings
passed to a particular synthesizer. The event unfolded as follows:



In the evening of October 9, 2016, someone posted a message to a public
forum which included giving out his remote client password, with an
"invitation" for anyone to connect to his computer. Within moments,
several
people connected to the poster's computer, but then the host
disconnected. A
few moments later, the server admin came in using the published
password,
changed some configurations and crashed NVDA by letting clients read
long
strings and making their keyboards unusable. An audio recording was
published that provides some live evidence, with people posting on
social
media advising others to stop using this, labeling this as "unsecure".



In light of this incident, as a community add-ons representative, I'd
like
to request that add-on users follow these guidelines:



1. Never give out NVDA remote session password publicly.

2. The Remote host must provide the password and this should be
done
privately.

3. The Remote client must tell host what he or she is going to
do so
the host can be aware of what's going on.

4. The host should try to inform clients that he or she is
disconnecting so clients can disconnect properly.



Also, as an add-on developer, I'd like to propose the following
action plan
in the future:



1. Please examine evidence you can find before coming to the
conclusion
that things are insecure.

2. Developers should provide responses as soon as possible when
evidence becomes available.



The add-on can be found in our NVDA Community Add-ons website. Although
there is some things about this add-on that have contributed to this
incident, the ultimate root cause has to do with irresponsible user
actions.



Thank you.

Cheers,

Joseph




.

Join nvda@nvda.groups.io to automatically receive all group messages.