[sldev] 3rd party viewer policy post on blogs.secondlife.com

[Dmitriy Kazimirov]

Won't work.
Basically you describe remote attestation system and for this to work you
must trust _all_ other components on system.
Let's suppose I'm Evil Hacker who wants to extract SKEY from Good Viewer.
(and I don't have my own as developer of Another Good Viewer)
Given _current_ situation with code I will simple write simple program which
inject Evil.dll into SecondLife.exe process and use Evil.dll to find SKEY.
Location of SKEY is know  from published sources
(In fact even this is not need. Ultinmate pirate tool called Debugger(for
example one from MSVS) couldl be more than enough).
SecondLife.exe can't protect against such tricks(well, it can try but it
will make compatibility problems, there are too much software which do code
injection for legitimate purposes. And if SecondLife.exe's protection
against this is good enough...well,I'm Evil Hacker, I will just use Evil
Kernel of Linux(and SecondLife will still support Linux,right?
Good luck validating _kernel_, especially some Linux distributions still
_require_ you to build your own kernel).
And of course were are even more ways.

But!
What could be done easily is making sure that _by_ default unsigned viewer
binary don't connect to Main Grid,
Sign key can only be got if your account is validated and signature IS
displayed.
Also, on connect grid responds back via chat (at random interval of 1-10
minutes) to user which viewer was used and who signed it according to what
grid see(random interval is make it difficult for Evil Viewer to modify this
response)
And make removal of this code not VERY easy to defer script kiddies.
(but not experienced devs).
It's very likely that this will be much better than today.
And it protects _users_ agains Evil Viewers

Anyway today difference between one of popular viewers which respects
permissions and same viewer which doesn't respect them is about 10 lines of
code. Yet I never saw 'non-respecting' version of this popular viewer






2009/10/21 Tigro Spottystripes <tigrospottystripes at gmail.com>

> what I was thinking was that the viewer binary would somehow be signed
> in a way that it could be verified as having been generated by someone
> that has been given a trust key from LL, the exactly how part went down
> the drain kinda
>
> Mike Dickson escreveu:
> > How does that help validate a viewer is "certified"?  I can see a OTP to
> > validate a user. The point with the GSM example is the source info is
> > "tamper proof."  I don't see that here with a viewer, especially an open
> > source one where source needs to be distributed.
> >
> > On Wed, 2009-10-21 at 15:59 +0000, Anders Arnholm wrote:
> >
> >> No the screat are probalt some muchg lnger than allen, it will be
> >> trasforemed with an algoritm.
> >>
> >>     f(SKEY, Challange)
> >>
> >> Is what are going to be sent,  this to make sure that KEY are not sent
> >> over the net and intercepter by anyone on the internet. The problem some
> >> to the viewer have to be able to make the calculation f(SKEY, Challange)
> >> to make this computation the coputer will need to have both the function
> >> f(k,c) and the SKEY someware. Whan you have both these to pices of
> >> information in one computer figuring out f() and SKEY are a trivial
> >> work.
> >>
> >
> >
> >
> >
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting
> privileges
>



-- 
--
Best Regards,
Dmitriy Kazimirov,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091021/ba2554d9/attachment.htm