m
Move page script moved page Secure Execution and Tainting to WoW:Secure Execution and Tainting without leaving a redirect
(New page: {{uitech}} The User Interface API's for Wow 2.0 have been updated to prevent scripted automation of decision making using the same code security model that protects the movement functions...) |
m (Move page script moved page Secure Execution and Tainting to WoW:Secure Execution and Tainting without leaving a redirect) |
||
| (One intermediate revision by one other user not shown) | |||
| Line 1: | Line 1: | ||
{{uitech}} | {{uitech}} | ||
The User Interface API's for WoW 2.0 have been updated to prevent scripted automation of decision making using the same code security model that protects the movement functions in prior releases. This means that several more of the API functions have been protected against execution from insecure code. | |||
The User Interface API's for | |||
A number of common WoW UI coding practices (most notably hooking) can easily cause problems in this model, preventing players from casting spells or performing actions, so I hope to explain how the security model works for developers in order for you to avoid these problems, as well as introducing some new Blizzard features to make existing ideas work under the new constraints. | A number of common WoW UI coding practices (most notably hooking) can easily cause problems in this model, preventing players from casting spells or performing actions, so I hope to explain how the security model works for developers in order for you to avoid these problems, as well as introducing some new Blizzard features to make existing ideas work under the new constraints. | ||
=Secure execution and "Tainting"= | ==Secure execution and "Tainting"== | ||
When WoW starts executing lua code, the execution starts off 'secure', and able to run protected functions. Execution remains secure until it encounters 'taint' - which is an indicator that a function or object came from an untrusted (AddOn or /script) source. The basic idea is that execution becomes 'tainted' as soon as it reads tainted data or executes tainted code, and any data written by a tainted execution is itself tainted. Protected functions refuse to operate when called from an execution path that is not secure. | When WoW starts executing lua code, the execution starts off 'secure', and able to run protected functions. Execution remains secure until it encounters 'taint' - which is an indicator that a function or object came from an untrusted (AddOn or /script) source. The basic idea is that execution becomes 'tainted' as soon as it reads tainted data or executes tainted code, and any data written by a tainted execution is itself tainted. Protected functions refuse to operate when called from an execution path that is not secure. | ||
| Line 11: | Line 10: | ||
When the UI first loads, all code and data from Blizzard signed FrameXML and AddOns (plus their saved variables) is secure, and all code and data from user provided AddOns (plus their saved variables) is tainted. | When the UI first loads, all code and data from Blizzard signed FrameXML and AddOns (plus their saved variables) is secure, and all code and data from user provided AddOns (plus their saved variables) is tainted. | ||
==What can be tainted?== | ===What can be tainted?=== | ||
All lua values and references can be tainted - local variables, global | All lua values and references can be tainted - local variables, global | ||
| Line 24: | Line 23: | ||
taint to the current environment. | taint to the current environment. | ||
=Hooking and the hooksecurefunc function= | ==Hooking and the hooksecurefunc function== | ||
The taint model is the reason that 'hooking' as it is commonly done today can easily break lots of UI functionality, trying to hook a function that is used by secure code causes a tainted function to be called in the middle of an otherwise secure execution path, this then taints the execution path so that nothing following the hook can use secure functions - don't be too dismayed however, we've been given a tool to get around this. | The taint model is the reason that 'hooking' as it is commonly done today can easily break lots of UI functionality, trying to hook a function that is used by secure code causes a tainted function to be called in the middle of an otherwise secure execution path, this then taints the execution path so that nothing following the hook can use secure functions - don't be too dismayed however, we've been given a tool to get around this. | ||
| Line 32: | Line 31: | ||
The 'special' feature of this secure hook is that when your hook function is executed, it executes with the taint that was present at the time the hook was created, and when your hook function is done that taint is discarded and the original secure (or possibly tainted - you cannot use hooksecurefunc to REMOVE taint, just avoid it) execution mode is restored. | The 'special' feature of this secure hook is that when your hook function is executed, it executes with the taint that was present at the time the hook was created, and when your hook function is done that taint is discarded and the original secure (or possibly tainted - you cannot use hooksecurefunc to REMOVE taint, just avoid it) execution mode is restored. | ||
=Protected frames and secure templates= | ==Protected frames and secure templates== | ||
WoW 2.0 also introduces a new Frame concept, protected frames, which act like normal frames out of combat, but when in combat cannot be programatically shown, hidden, re-sized or re-anchored, nor can its attributes be changed. Once a frame has been declared protected it cannot be made unprotected, and protection is inherited from templates. You can still initiate user moving or sizing of protected frames while in combat, you just cannot use lua to move them. Secure code is allowed to bypass this restriction. | WoW 2.0 also introduces a new Frame concept, protected frames, which act like normal frames out of combat, but when in combat cannot be programatically shown, hidden, re-sized or re-anchored, nor can its attributes be changed. Once a frame has been declared protected it cannot be made unprotected, and protection is inherited from templates. You can still initiate user moving or sizing of protected frames while in combat, you just cannot use lua to move them. Secure code is allowed to bypass this restriction. | ||
| Line 42: | Line 41: | ||
The secure templates are configured using the new frame attribute methods, these can only be used outside of combat, and set a named attribute to a specific lua value, discarding the value's taint. | The secure templates are configured using the new frame attribute methods, these can only be used outside of combat, and set a named attribute to a specific lua value, discarding the value's taint. | ||
=Terminology= | ==Terminology== | ||
Since there are a number of similar concepts at work here, the terminology can | Since there are a number of similar concepts at work here, the terminology can | ||
be confusing, here's a summary of the common terms and their meanings: | be confusing, here's a summary of the common terms and their meanings: | ||
| Line 53: | Line 52: | ||
* A protected method is one that cannot be successfully called on a protected frame during combat. | * A protected method is one that cannot be successfully called on a protected frame during combat. | ||
* Secure templates are simply XML templates that define secure script handlers, they usually also create protected frames. | * Secure templates are simply XML templates that define secure script handlers, they usually also create protected frames. | ||
{{API Trail Secure}} | |||