|
|
|
[
Permlink
| « Hide
]
Corsi Mousehold added a comment - 17/Sep/07 10:02 AM
I honestly am not sure why this was not part of the programming for the request originally. But this will save ALOT of issues and help SL in general.
A change to the "MaxAnimationRequestQueueDepth" to be <= 3 would defang this particular DOS style attack at the source neatly.
Animation requests from griefer cubes can come in at a very high rate, 1-5+ per second if there are many cubes in the 96M range, and the animation request queue depth grows rapidly. A lost legit new animation request with an existing request queue depth <= 3 would be a rare event and of no serious in game experience loss. Requests > 3 should fail silently to keep things simple. Thanks! I wrote a patch to throttle requests from a single task owner. If more than a certain number of requests in a row come from the same owner, then it silently drops them.
I'd keep the limit high on this type of throttle. For example my "copycat" game will ask again if you deny it permission_debit, so I'd say keep this at least 10-20.
I should also point out, my patch is complimentary with Dale's.. they aren't mutually exclusive, and both work to mitigate the attack in different ways. Dale's fixes the problem on a longer term basis, and mine obviates the need to relog after such an attack.
10-20 is far too high, as you will end up having to click 10-20 times when a griefer object is spamming you to death.
I suggest the queue depth default at 3, and then be configurable as a Debug Settings parameter for those who require a deeper queue capability. Mako. 3 is utterly stupid.
All the no buttons are at the same point. You just have to position your mouse over that point, and click 20 times. P{erhaps you have feeble hands, but I can easily click 20 times in under 3 seconds. 3 is too low to be useful for the reason WarKirby points out. But War - try not to be so vicious about it.
 Actually I think 3 was a quite good number.
It seems people haven't actually read the patch That said, the patch is also buggy. At first glance: It declares a static char array, then doesn't initialize it, and uses strcmp on it. BAD! Not a bug but also not good: The count is for requests from the same avatar in a sequence, but no timestamp is kept. I think the count should reset after say, 20 seconds pass. This avoids requests sent by somebody while you're away from getting lost. Yes, I'm in the middle of redoing Gigs' patch. It's a great concept, but it would kill someone testing their own scripts without the sequence expiring.
There's an existing throttling mechanism that throttles based on the number of times an event happens attributed to an LLUUID each second. I'm refactoring that to work with arbitrary data types, and moving it from simulator code to llcommon, and I'm using this. it should be noted mute_button.patch does not work as implimented the line
gMuteListp->add(LLMute(cbdata->mItemID, cbdata->mObjectName, LLMute::OBJECT)); should be gMuteListp->add(LLMute(cbdata->mTaskID, cbdata->mObjectName, LLMute::OBJECT)); ItemID refers to the key of the script TaskID refers to the key of the object containing the script. I can personally think of a reason why 3 wouldn't be enough. Objects need permission to attach to the avatar. I have plans for a transforming sull prim avatar, of sorts. The only feasible way top do it is to rez all the parts, and have them flood the owner with attach requests, so they can attach.
Perhaps some compromise, allowing a higher limit from objects you own. That would work. How was the internal fix implemented? Any ideas on what the set point for throttling was? And how will this affect scripts that only direct their attention at the owner, wherein we need to be spammed for testing?
oh. Another issue. ignoring only mass requests from one av, could lead to griefers using multiple accounts at the same time, much like multiple scripts are used to work around script delays.
This issue is a central one in the whole blue dialog affair, yet it's rather hard to find. I've linked it to a few more similar issues, which should raise visibility.
I've changed all fixed internally issues to Resolved: Fix pending.
This fix I assume went live, because it has already messed up me rezzing my own vendors. I get capped at 5 requests from objects, and any queued requests over 5 get blacklisted until I either log off or leave the sim and come back. No timer was put into place to un-blacklist. This is not a viable solution as we sometimes need to turn this security OFF. It's silly when a prim and script that I created and own gets blacklisted by my own client.
Voted purely for the sake of a mute button, as I was spammed by blue box messages that had none, and very slowly the framerate dropped until I crashed. By the time I realized the messages were probably still piling on, it was too late to use the Mute dialog to perform a search for the troublesome avatar. Thus I suppose an absolute limit of held messages (64?) would be handy purely for the sake of stability. I crashed on a normally smoothly running system:
Second Life 1.22.4 (106127) Dec 16 2008 12:22:22 (Second Life Release Candidate) I don't see the need to do really restrictive message throttling. 16 messages or so from any one outside agent allowed once every 30 seconds wouldn't even get annoying (or I'd mute it before it got to be). Then again I did get a score of 112 on http://www.urban75.com/Mag/java7.html Voted simply because Linden Lab has a responsibility to actually implement things they claim are fixed internally. If there is a good reason why this isn't, or it's made redundant by other changes, then please just let us know so we can close this issue.
I could create an object to spam someone visiting a given sim, crashing them each time they arrive.
Literally nothing they can do about it. I'd never do anything to risk loosing what I've created in SL, sadly this view is not shared by all. Useless fixe aka they (if i can they can) will create a workaround; Only Valid fix; Another Issue closely related; Reopening. We had this for a while, and it looks like it got stomped on by the notifications rework.
Damen Hax wrote: -Deeding to group allowing partial anonymity
In the third-party viewer GEMINI we can see in the build/editor menu not only the owner and the creator, but also the LAST OWNER. This is very useful for griefing objects deeded to a group. We see the last and in this case the actual owner (to whom the object is returned). So LL has already a LAST OWNER entry, it would be nice to show it not only in third-party viewers, but also in the LL viewers. That would make it easier to write abuse reports in case of griefing abuse of deeding objects. Removing patch attached flag because the patch is no longer applicable to the codebase
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Reopened
Normal
Add mute button to script notices
