| Key: |
VWR-3561
|
| Type: |
Bug
|
| Status: |
Resolved
|
| Resolution: |
Duplicate
|
| Priority: |
Critical
|
| Assignee: |
Unassigned
|
| Reporter: |
WarKirby Magojiro
|
| Votes: |
49
|
| Watchers: |
13
|
|
If you were logged in you would be able to see more operations.
|
|
|
|
Issue Links:
|
Duplicate
|
|
This issue duplicates:
|
|
|
SVC-3514 llLoadUrl (and other LLMessageBox-generating functions) should be per-agent throttled, not delayed
|
|
|
|
|
|
This issue is original of duplicate:
|
|
VWR-13913
Excessive, unlimited, uncapped scripted dialogs crash viewer, used for greifing
|
|
|
|
|
Relates
|
|
This issue Relates to:
|
|
VWR-2046
Focus is sent to menu/money/notification window
|
|
|
|
 |
|
SVC-456 Meta-Issue: Improved Anti-Griefer Tools
|
|
|
|
|
|
|
|
|
|
|
This issue is related to by:
|
|
|
VWR-6964 Muting object (or object owner) does not mute dialogs
|
|
|
|
 |
|
VWR-12541 prim spammer cuases you to crash when you try to file an abuse report
|
|
|
|
|
|
|
VWR-9204 Clicking the mute button from a dialog when receiving a landmark or a notecard (spam) will crash the viewer if there are pending notifications behind the dialog
|
|
|
|
|
|
|
|
|
|
|
SVC-4243
LLNotifyBox-creating functions need serious throttling.
|
|
|
|
|
|
|
VWR-14810 Overhaul the Mute function: Make it worth using!
|
|
|
|
|
|
|
VWR-4832 Notifications and Alerts redesign
|
|
|
|
|
|
|
|
|
|
|
|
MISC-2481 BAN weapons that use repetitive llDialog
|
|
|
|
|
|
|
VWR-14370 Dialog Boxes can block a lot of functionality
|
|
|
|
|
|
VWR-2502 Add mute button to script notices
|
|
|
|
|
|
|
| Linden Lab Issue ID: |
DEV-7359
|
Blue dialog boxes steal focus. they are also capable of overloading the victim's viewer.
By spamming a client repeatedly with hundreds of blue dialog menus, the victim's client framerate will gradually decrease as the dialogs stack up, and if left for a few minutes, the viewer will crash from the sheer load.
My solution. I'm thinking a dual throttle. On the client end, a throttle on the number of urls/dialogs/permission requests which can be active from a particular user at any given time. Say..5-10. And on the server, another per-sim throttle for any script which uses these functions excessively. Say 40 uses in 20 seconds or more. This throttle could be done grey goo style. ie, once the thottle is hit, all farther calls to the function from that user in that sim, would be blocked, until the rate of calling falls below the threshold.
|
|
Description
|
Blue dialog boxes steal focus. they are also capable of overloading the victim's viewer.
By spamming a client repeatedly with hundreds of blue dialog menus, the victim's client framerate will gradually decrease as the dialogs stack up, and if left for a few minutes, the viewer will crash from the sheer load.
My solution. I'm thinking a dual throttle. On the client end, a throttle on the number of urls/dialogs/permission requests which can be active from a particular user at any given time. Say..5-10. And on the server, another per-sim throttle for any script which uses these functions excessively. Say 40 uses in 20 seconds or more. This throttle could be done grey goo style. ie, once the thottle is hit, all farther calls to the function from that user in that sim, would be blocked, until the rate of calling falls below the threshold. |
Show » |
made changes - 30/Nov/07 07:42 PM
| Field |
Original Value |
New Value |
|
Link
|
|
This issue is related to by VWR-3558
[ VWR-3558
]
|
made changes - 01/Dec/07 08:22 AM
|
Link
|
|
This issue is duplicated by SVC-1012
[ SVC-1012
]
|
made changes - 01/Dec/07 08:23 AM
|
Link
|
This issue is duplicated by SVC-1012
[ SVC-1012
]
|
|
made changes - 01/Dec/07 08:26 AM
|
Link
|
|
This issue is related to by SVC-1012
[ SVC-1012
]
|
made changes - 03/Dec/07 11:13 AM
|
Description
|
Blue dialog boxes are a nasty weapon, as I'm sure we're all aware. In addition to the focus stealing, they are also capable of overloading the victim's viewer. By spamming a client repeatedly with hundreds of blue dialog menus, the victim's client framerate will gradually decrease as the dialogs stack up, and if left for a few minutes, the viewer will crash from the sheer load.
This exploit is already in use in several weapons in SL. one example can be found here:
http://slurl.com/secondlife/Meyers/89/73/495
The Quantum Core combat system, contains a barely hidden module named Crash, which does exactly this. Using llLoadURL, with a large array of slave scripts to circumvent the script delay, the weapon spams the victim with hundreds of meaningless URLs, causing a drtop in client performance, and eventually a crash.
This is something which really needs to be fixed. Exploits which affect you inworld, is one thing. But an exploit that allows crashing of the client, on your own computer, is on a whole other level. The exact solution is open to debate.
My solution. I'm thinking a dual throttle. On the client end, a throttle on the number of urls/dialogs/permission requests which can be active from a particular user at any given time. Say..5-10. And on the server, another per-sim throttle for any script which uses these functions excessively. Say 40 uses in 20 seconds or more. This throttle could be done grey goo style. ie, once the thottle is hit, all farther calls to the function from that user in that sim, would be blocked, until the rate of calling falls below the threshold.
|
Blue dialog boxes are a nasty weapon, as I'm sure we're all aware. In addition to the focus stealing, they are also capable of overloading the victim's viewer. By spamming a client repeatedly with hundreds of blue dialog menus, the victim's client framerate will gradually decrease as the dialogs stack up, and if left for a few minutes, the viewer will crash from the sheer load.
This exploit is already in use in several weapons in SL. one example can be found here:
http://slurl.com/secondlife/Meyers/89/73/495
The Quantum Core combat system, contains a barely hidden module named Crash, which does exactly this. Using llLoadURL, with a large array of slave scripts to circumvent the script delay, the weapon spams the victim with hundreds of meaningless URLs, causing a drop in client performance, and eventually a crash.
This is something which really needs to be fixed. Exploits which affect you inworld, is one thing. But an exploit that allows crashing of the client, on your own computer, is on a whole other level. The exact solution is open to debate.
My solution. I'm thinking a dual throttle. On the client end, a throttle on the number of urls/dialogs/permission requests which can be active from a particular user at any given time. Say..5-10. And on the server, another per-sim throttle for any script which uses these functions excessively. Say 40 uses in 20 seconds or more. This throttle could be done grey goo style. ie, once the thottle is hit, all farther calls to the function from that user in that sim, would be blocked, until the rate of calling falls below the threshold.
|
made changes - 05/Dec/07 08:15 AM
|
Link
|
|
This issue Relates to VWR-2046
[ VWR-2046
]
|
made changes - 05/Dec/07 04:23 PM
|
Link
|
|
This issue is related to by VWR-2502
[ VWR-2502
]
|
made changes - 11/Dec/07 09:59 AM
|
Linden Lab Issue ID
|
|
DEV-7359
|
made changes - 22/Dec/07 02:17 AM
|
Workflow
|
jira
[ 17359
]
|
jira-2007-12-21
[ 25005
]
|
made changes - 22/Dec/07 02:28 AM
|
Workflow
|
jira
[ 25005
]
|
jira-2007-12-21
[ 25684
]
|
made changes - 22/Dec/07 03:19 PM
|
Workflow
|
jira-2007-12-21
[ 25684
]
|
jira-2007-12-22
[ 31913
]
|
made changes - 22/Dec/07 03:40 PM
|
Workflow
|
jira-2007-12-21
[ 31913
]
|
jira-2007-12-22
[ 33980
]
|
made changes - 22/Dec/07 08:33 PM
|
Workflow
|
jira-2007-12-22
[ 33980
]
|
jira-2007-12-22a
[ 39111
]
|
made changes - 22/Dec/07 08:58 PM
|
Workflow
|
jira-2007-12-22
[ 39111
]
|
jira-2007-12-22a
[ 40585
]
|
made changes - 22/Dec/07 09:50 PM
|
Workflow
|
jira-2007-12-22
[ 40585
]
|
jira-2007-12-22a
[ 43067
]
|
made changes - 22/Dec/07 10:12 PM
|
Workflow
|
jira-2007-12-22
[ 43067
]
|
jira-2007-12-22a
[ 44429
]
|
made changes - 19/Feb/08 05:04 PM
|
Link
|
|
This issue is related to by VWR-4832
[ VWR-4832
]
|
made changes - 15/Sep/08 08:28 AM
|
Link
|
|
This issue is related to by VWR-9204
[ VWR-9204
]
|
made changes - 13/Nov/08 11:02 AM
|
Workflow
|
jira-2007-12-22a
[ 44429
]
|
jira-2008-11-14
[ 62521
]
|
made changes - 13/Nov/08 11:18 AM
|
Workflow
|
jira-2007-12-22a
[ 62521
]
|
jira-2008-11-14
[ 68290
]
|
made changes - 13/Nov/08 04:34 PM
|
Workflow
|
jira-2008-11-14
[ 68290
]
|
jira-2008-11-14a
[ 88253
]
|
made changes - 13/Nov/08 04:50 PM
|
Workflow
|
jira-2008-11-14
[ 88253
]
|
jira-2008-11-14a
[ 93479
]
|
made changes - 13/Nov/08 05:00 PM
|
Workflow
|
jira-2008-11-14
[ 93479
]
|
jira-2008-11-14a
[ 97284
]
|
made changes - 13/Nov/08 05:11 PM
|
Workflow
|
jira-2008-11-14
[ 97284
]
|
jira-2008-11-14a
[ 101196
]
|
made changes - 13/Nov/08 05:29 PM
|
Workflow
|
jira-2008-11-14
[ 101196
]
|
jira-2008-11-14a
[ 108341
]
|
made changes - 13/Nov/08 05:50 PM
|
Workflow
|
jira-2008-11-14
[ 108341
]
|
jira-2008-11-14a
[ 115299
]
|
made changes - 13/Nov/08 06:04 PM
|
Workflow
|
jira-2008-11-14
[ 115299
]
|
jira-2008-11-14a
[ 120817
]
|
made changes - 13/Nov/08 06:27 PM
|
Workflow
|
jira-2008-11-14
[ 120817
]
|
jira-2008-11-14a
[ 129079
]
|
made changes - 13/Nov/08 06:44 PM
|
Workflow
|
jira-2008-11-14
[ 129079
]
|
jira-2008-11-14a
[ 135543
]
|
made changes - 11/Jan/09 05:28 AM
|
Link
|
|
This issue is related to by VWR-11492
[ VWR-11492
]
|
made changes - 09/Mar/09 09:35 PM
|
Link
|
|
This issue is related to by MISC-2481
[ MISC-2481
]
|
made changes - 09/May/09 10:13 PM
|
Affects Version/s
|
|
1.22
[ 10430
]
|
made changes - 10/May/09 02:30 PM
|
Status
|
Open
[ 1
]
|
Resolved
[ 5
]
|
|
Fix Version/s
|
|
1.20
[ 10350
]
|
|
Resolution
|
|
Fixed
[ 1
]
|
made changes - 10/May/09 03:22 PM
|
Resolution
|
Fixed
[ 1
]
|
|
|
Status
|
Resolved
[ 5
]
|
Reopened
[ 4
]
|
made changes - 10/May/09 06:31 PM
|
Status
|
Reopened
[ 4
]
|
Resolved
[ 5
]
|
|
Fix Version/s
|
1.20
[ 10350
]
|
|
|
Resolution
|
|
Fixed
[ 1
]
|
made changes - 10/May/09 06:56 PM
|
Resolution
|
Fixed
[ 1
]
|
|
|
Status
|
Resolved
[ 5
]
|
Reopened
[ 4
]
|
made changes - 10/May/09 08:11 PM
|
Description
|
Blue dialog boxes are a nasty weapon, as I'm sure we're all aware. In addition to the focus stealing, they are also capable of overloading the victim's viewer. By spamming a client repeatedly with hundreds of blue dialog menus, the victim's client framerate will gradually decrease as the dialogs stack up, and if left for a few minutes, the viewer will crash from the sheer load.
This exploit is already in use in several weapons in SL. one example can be found here:
http://slurl.com/secondlife/Meyers/89/73/495
The Quantum Core combat system, contains a barely hidden module named Crash, which does exactly this. Using llLoadURL, with a large array of slave scripts to circumvent the script delay, the weapon spams the victim with hundreds of meaningless URLs, causing a drop in client performance, and eventually a crash.
This is something which really needs to be fixed. Exploits which affect you inworld, is one thing. But an exploit that allows crashing of the client, on your own computer, is on a whole other level. The exact solution is open to debate.
My solution. I'm thinking a dual throttle. On the client end, a throttle on the number of urls/dialogs/permission requests which can be active from a particular user at any given time. Say..5-10. And on the server, another per-sim throttle for any script which uses these functions excessively. Say 40 uses in 20 seconds or more. This throttle could be done grey goo style. ie, once the thottle is hit, all farther calls to the function from that user in that sim, would be blocked, until the rate of calling falls below the threshold.
|
Blue dialog boxes steal focus. they are also capable of overloading the victim's viewer.
By spamming a client repeatedly with hundreds of blue dialog menus, the victim's client framerate will gradually decrease as the dialogs stack up, and if left for a few minutes, the viewer will crash from the sheer load.
My solution. I'm thinking a dual throttle. On the client end, a throttle on the number of urls/dialogs/permission requests which can be active from a particular user at any given time. Say..5-10. And on the server, another per-sim throttle for any script which uses these functions excessively. Say 40 uses in 20 seconds or more. This throttle could be done grey goo style. ie, once the thottle is hit, all farther calls to the function from that user in that sim, would be blocked, until the rate of calling falls below the threshold.
|
made changes - 10/May/09 08:13 PM
|
Priority
|
Critical
[ 2
]
|
Normal
[ 4
]
|
made changes - 10/May/09 09:17 PM
|
Priority
|
Normal
[ 4
]
|
Critical
[ 2
]
|
made changes - 11/May/09 08:30 PM
|
Link
|
|
This issue is related to by SVC-4243
[ SVC-4243
]
|
made changes - 12/May/09 12:36 AM
|
Link
|
|
This issue is original of duplicate SVC-4243
[ SVC-4243
]
|
made changes - 12/May/09 01:00 AM
|
Link
|
This issue is original of duplicate SVC-4243
[ SVC-4243
]
|
|
made changes - 06/Jun/09 08:26 PM
|
Link
|
|
This issue is original of duplicate VWR-13913
[ VWR-13913
]
|
made changes - 07/Jun/09 10:31 AM
|
Link
|
|
This issue Relates to SVC-456
[ SVC-456
]
|
made changes - 07/Jun/09 10:31 AM
|
Link
|
This issue is related to by SVC-1012
[ SVC-1012
]
|
|
made changes - 07/Jun/09 10:32 AM
|
Link
|
|
This issue Relates to SVC-1012
[ SVC-1012
]
|
made changes - 07/Jun/09 06:09 PM
|
Link
|
|
This issue is related to by VWR-6964
[ VWR-6964
]
|
made changes - 10/Jun/09 08:29 AM
|
Status
|
Reopened
[ 4
]
|
Resolved
[ 5
]
|
|
Resolution
|
|
Duplicate
[ 3
]
|
made changes - 10/Jun/09 08:29 AM
|
Link
|
|
This issue duplicates SVC-3514
[ SVC-3514
]
|
made changes - 14/Jun/09 09:15 AM
|
Link
|
|
This issue is related to by VWR-12541
[ VWR-12541
]
|
made changes - 25/Jun/09 02:17 PM
|
Link
|
|
This issue is related to by VWR-14370
[ VWR-14370
]
|
made changes - 08/Jul/09 02:28 PM
|
Affects Version/s
|
|
1.23
[ 10470
]
|
|
Affects Version/s
|
1.22
[ 10430
]
|
|
made changes - 08/Jul/09 02:39 PM
|
Affects Version/s
|
|
1.22
[ 10430
]
|
made changes - 22/Jul/09 03:09 PM
|
Link
|
|
This issue is related to by VWR-14810
[ VWR-14810
]
|
|
