|
|
|
I agree in theory, Lex. But all the exploits I report, like the damage one, are those which are already widely known. For example, I made a point of not revealing the security implications of SVC-997 because as far as I'm aware, only a very select few people know of it, and it's best to keep it that way. But with exploits which are known to anyone who's ever dabbled in weaponry, I think it's foolish to pretend they can be hidden.
With full disclosure, people can be made aware that there is a danger, and take precautions to protect themselves. Furthermore, those who might have used it, can be made aware that it's an exploit, and realise it would be a bad idea to utilise it for any commercial product, as it will likely lead their reputation to suffer when their devices mysteriously break. But the thing is, that damage exploit is now MORE widely known than it was. I, for one, didn't know about it. You might've just given some people some ideas that they didn't have before. And there's nothing we can do about it. The only protection I can think of is not to sit, which is kind of silly. This isn't like bugtraq, where people can remove the offending daemon from their system or otherwise take precautions. There's not much we can do. And as to your final point, the people who are going to use this kind of thing aren't the kind of people who will care that they're breaking the rules.
This is the classic "disclosure versus notification of vendors" problem. Full disclosure is a powerful tool, but it's generally agreed that it's important to give the vendor a chance to fix the bug before telling everyone and putting them on an emergency footing. It's been available to anyone for a long time. The item I pointed out in the issue is available for a mere 250l to anyone, and has been for ages. In fact, almost every major combat system on slex boasts the ability to kill people in safe zones.
We're still arguing on the principle of the matter, though, not on this specific case. Like I said, I don't want to encourage people to report exploits in PJIRA. In short, I don't think they have a place in PJIRA, but this meta-issue seems to create a home for them.
There is another point, though. Some of these issues. like
sometimes, debate on the exact solution to a problem is needed, and that can't happen if noone knows about it. But things like warppos or megaprims or possible griefing vectors seem like non-security exploits? The line there isn't very clear-cut. Something that's obviously server-side permissions-related (copy a no-copy, etc.) should go to LL directly - but I doubt LL meant that things like griefing tactics should be sent to "security@...", especially if they can be blocked viewer-side?
I'm just trying to guess LL's intentions here; I'm still on the fence about my own opinion on making these tactics public. The scope of this meta-issue is kinda iffy too - a "positive" hack can become a "negative" exploit at any time if someone figures out a way to abuse it. Well, I suppose the change to "Negative Exploits" is an improvement, but I still don't like it. I don't like the distinction between negative and positive exploits, and I don't want issue reporters to have to make that decision before deciding whether to post an exploit to the JIRA. I also don't want them to see this and then argue that a huge 0-day permissions exploit was a "positive exploit". I still think this meta-issue might encourage exploits to be reported in JIRA when they should be sent directly to LL.
Someone should add this issue to the bug triage so that we can get the Lindens' take on it. Yes, please go ahead and add this to the bug triage agenda and I'll also ping our devs in Studio Blacklight (focusing on critical issues) to have a look.
Also importing this to ask Resident Experience & Governance Teams for design feedback...
You imported a meta issue?
This is just an organisation thing. You're supposed to import the issues it points to >_> @WarKirby: Yes, I know generally that's the case, and some of those related issues have also been imported. Reason why I imported this Meta-Issue is because cohesive design is needed – a Meta-Issue helps with a "broader overview", NOT because the Meta-Issue is actionable itself. Especially because these issues are very cross-departmental at Linden Lab and some depts. don't use JIRA as frequently as others.
If I update this meta issue, will the changes be reflected in the internal version ? I know of at least 8 other things I want to add to this once I'm done testing them.
Linked SVC-1042.
That's a parent issue which encompasses 4 of the things I was going to link here, as sub tasks. I chose that method as they're all similarly related to each other. Created today as a result of another round of bughunting. @WarKirby: I'm recommending that involved Lindens look to this external Meta-Issue to see the latest linked issues.
I was going to ask the same thing, very suspicious for a linden to close a meta issue especially without comment, I'm assuming that this was a mistake of some sort until there's reason to believe otherwise.
Sidewinder closed a meta issue about avatar physics in H4 at around the same time. That's justified, as the havok 4 project is going live. Perhaps he somehow thought this falls under the same umbrella?
It's far from finishes yet, until SL is completely free of exploits. and I certaoinly know it isn'. I've seen quite a few worrying things I'd be posting jiras for if I knew how they were done, and I've been meaning to make one about autoreturn evasion methods soon. I'm linking
This issue has been around a LONG time. The resident who was going to fix it, Dale Glass, seems unlikely to do so now. his client hasn't been updated since 1.18, and I sincerely doubt he plans to do anything about this issue. It's time for LL to step in and take care of it. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Meta Issue
Reopened
Critical
Meta Issue: Negative Exploits
Exploits shouldn't be reported on this JIRA, especially exploits LL doesn't know yet. Instead, those issues should be emailed to security@lindenlab.com. I'm NOT proposing that security through obscurity is a good idea here, but I do want to point out that with a system as large as SL, it's going to take a minimum of a day or two to speed-patch an extremely severe exploit, and probably longer to patch less severe ones (such as
SVC-774). I don't like the idea of inviting or encouraging people to report exploits on this JIRA by having this meta issue.I also don't like your description/explanation of "exploit". An exploit is simply "a bug that allows residents to do something they shouldn't be allowed to do". Examples: give away no-transfer objects, copy no-copy objects, steal money from others, make free money, circumvent autoreturn, view no-modify scripts, etc. You beat around the bush and don't really get around to the bottom line: that these are security vulnerabilities.
Megaprims actually are an exploit... or rather, the bug that allowed them to be created was. It allowed someone to create prims that they shouldn't have been able to create. One could even say that there's still an exploit that allows these objects to continue to exist. Warppos is a little bit of a grey area, but I think it's still an exploit since it allows people to circumvent the intended delay on llSetPos(). Neither of these is as big as other exploits that've been seen in SL.