[opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?
phox at modularsystems.sl
Sat Aug 21 16:48:48 PDT 2010
I feel I need to take a moment here to address some of this:
First of all, the issue with the login screen was NOT an attempt at
DDOS, Fractured was looking at traffic graphs for the website in
question and thought it would be funny to mess with them by making the
traffic go from ~150 hits a day to several hundred thousand. He was
simply messing with page views on the site, it was a stupid thing to do
no doubt, but it was not a DDOS attack.
The website in question suffered no ill effects, and to imply that
loading a .php and a few images is an attempt at DDOS is just
ridiculous, our login page consists of a .php script a hi-res picture,
and our website doesn't go down as a result.
As far as emkdu goes: the issue originally brought to my attention (I'm
the developer who maintains emkdu) was that linux and mac versions were
encoding a full path which COULD include a username. I corrected that
issue as soon as it was brought to my attention.
The so called "second" incident involved the path being encoded on
windows, at the time, I saw no reason to update the windows version of
emkdu because path on windows was simply "c:\Program Files\Emerald\",
there was no important information there. When I realized that if a user
decided to install to desktop it would include their operating system
username, I changed the windows copy as well. (Since then, all
additional metadata information has been removed from emkdu).
The change in encryption was simply a result of inertia being able to
decode the viewer window title information. Users of that viewer were
using the window title information in order to target users of older
Emerald viewers with crash exploits and similar.
On 8/21/2010 7:21 PM, opensource-dev-request at lists.secondlife.com wrote:
> As someone who was using the Emerald viewer at the time this was going
> on, I researched this subject with some concern.
> It doesn't matter who the target was at all, whether he is a good guy
> or a bad guy, it's not of consequence. ModularSystems is responsible
> for using my login process to send a sizeable body of undisclosed,
> irrelevant traffic to harass someone. This isn't just 'embarassing',
> it's unacceptable from inception to execution.
> This simply adds to the ongoing pattern of Third Party Viewer Policy
> violations already exposed regarding ModularSystems builds of Emerald
> that speak to a culture of irresponsibility in the persons that
> control the ModularSystems site. I am not lawyer, but just looking at
> the third party viewer policy I can pick out a number of criteria that
> might not be met.
> TPVP 2.d : "You must not launch Denial of Service ("DoS") attacks,
> engage in griefing, or distribute other functionality that Linden Lab
> considers harmful or disruptive to Second Life or the Second Life
> community. " This appears to be violated by code in the viewer's
> login pagehttp://webcache.googleusercontent.com/search?q=cache:jD_B973EpVUJ:modularsystems.sl/app/login/+http://modularsystems.sl/app/login/
> TPVP 1.C.iii There must be disclosure of "Any surprising or unexpected
> functionality, including any limitations on features and functionality
> generally available to Second Life users through Linden Lab's
> viewers.". The leakage of pathnames in by emdku code does not appear
> to have been disclosed, despite it being an internal topic of
> discussion months earlier. The leakage of any information, regardless
> of how innocent, to other avatars via the path of baked textures
> hasn't been disclosed even now to my knowledge.
> TPVP 3.B.iii Distribution must adhere to the terms of the GPL 2.0.
> ModularSystems may not be distributing emkdu in a way that qualifies
> it as a separate work under the GPL. It's transparently distributed to
> the user's system without notification. No alternatives (such as
> llkdu, openjpeg) or opt-out options are presented, and the library is
> linked by the emerald runtime. Since the emkdu source is not
> distributed, the distribution of the viewer may be in violation.
> Compare this with other viewers such as CoolViewer and Imprudence with
> specifically deal with distribution of closed source binaries as a
> completely separate, user-initiated, optional process to fullfill GPL
> 2.0 compliance.
> TPVP 6.3 : "Your Second Life accounts must be in good standing, must
> not be suspended, and must not have been permanently banned or
> terminated". The operators of the Modular Systems website possess
> accounts that have been permanently banned or terminated and readily
> acknowledge this.
> Beyond the above, the way in which these issues were addressed are
> concerning. The emdku issue was only addressed because someone from
> outside ModularSystems exposed it. The DDoS came to light because it
> was exposed from the outside. There may not be a history of
> ModularSystems successfully policing themselves. It appears that those
> who try end up leaving the project.
> External communication similarly does not inspire confidence. On the
> ModularSystem web page, there is no mention of emkdu and how in
> released builds it leaked information. Neither is there a patch or new
> download listed. The tone of communication is slanted to draw diminish
> critics, instead of clearly articulate information for users to make
> an informed decision. As a user I had to read other blogs and talk to
> developer peers personally to find out what was really happening.
> ModularSystems didn't tell me.
> On this thread an Emerald developer stated that many of these issues
> stem from the people who control ModularSystems being less than
> responsible and embarrassing the team. One has to ask if this is the
> case, why not vote "No Confidence" and move your website and your
> builds to someplace with greater credibility, and change LL's official
> point of contact for Emerald from "ModularSystems" to something else?
More information about the opensource-dev