UI & MACROS FORUM

Forum Nav:

WoW Technical SupportMac Technical SupportCustomer Service ForumWoW Realm StatusUI & Macros ForumBug Report Forum---------------------------------------Druid DiscussionRogue DiscussionPriest DiscussionHunter DiscussionShaman DiscussionWarrior DiscussionMage DiscussionPaladin DiscussionWarlock Discussion---------------------------------------WoW Professions DiscussionWoW PvP DiscussionWoW Quest DiscussionRealm ForumsBlizzard ArchiveWoW Off-topic DiscussionWoW SuggestionsWoW Guild RecruitmentWoW Guild RelationsWoW Role-PlayingWoW GeneralWoW Raids & DungeonsTest Realm ForumWoW Guide ForumWelcome to WoWWoW Battlegroup Forums

Topic Guide to Secure Execution and Tainting

|  01/28/2007 06:48:14 AM UTC

1 . 2 . 3 . 4

60

Iriel

< The Vigilance Commit… >

Silver Hand

0. Guide to Secure Execution and Tainting  |  10/13/2006 06:19:46 PM UTC

Secure Execution and Tainting

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.

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"

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 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?

All lua values and references can be tainted - local variables, global

variables, table keys, table values:

* When new values are created (e.g. local x = 2) then they inherit the current taint of their execution path.

* When code accesses secure values, the resulting value will be tainted by the current execution path (but the original value remains clean).

* When code accesses tainted values, the resulting value will remain tainted and the execution path is also tainted.

* When code sets global values, the resulting value has the taint of the execution path.

Function closures can also be tainted, executing a function closure applies its

taint to the current environment.

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 new hooksecurefunc API function allows AddOn code to 'post hook' a secure global function, that is run another function after the original one has been run. So for example you could track calls to CastSpellByName using hooksecurefunc("CastSpellByName", mySpellCastTracker). The API replaces the original global function with its own secure hook function that calls the original function, saves its return values away, and then calls your hook function with the same arguments as the original function (any return values from your hook function are thrown away) and then it returns the return values from the original.

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.

(continued...)

UI and Macros Forum MVP - Understand GC!

60

Iriel

< The Vigilance Commit… >

Silver Hand

1. Re: Guide to Secure Execution and Tainting  |  10/13/2006 06:20:57 PM UTC

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.

The control restrictions on protected frames also get applied to their parents and any frames they are anchored to. This is important when anchoring a protected frame to another normally non-protected frame, as it can lead to unexpected and often undesired behavior. This propagation is temporary, and re-anchoring or re-parenting the frame out of combat can release the restriction.

Protected frames are important because they form the basis of the Blizzard action and spell buttons, but also because they allow for some new secure button templates. Since normal AddOn code is tainted, it cannot change targets or perform actions directly, however WoW 2.0 contains a number of secure templates which can be inherited by AddOn code. These secure templates provide one or more secure handlers, usually OnClick, that use frame attributes to perform actions. When a secure template is inherited then any handlers it defines remain secure unless they are overridden by the inheriting frame (or another template).

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

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:

* Secure generally means 'without taint'.

* Secure code refers to either an untainted current execution or an untainted function.

* Values/References/Parameters are sometimes referred to as 'clean', this means the same as 'secure'.

* A protected function is one that can only be successfully called from a secure execution state.

* A protected frame is one that is locked down 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.

Last Updated: 2006-10-13 11:15am

UI and Macros Forum MVP - Understand GC!

Slouken

Blizzard Poster

2. Re: Guide to Secure Execution and Tainting  |  10/13/2006 06:38:06 PM UTC

Great explanation, thanks Iriel!

60

Potillan

< Flawed >

Archimonde

3. Re: Guide to Secure Execution and Tainting  |  10/13/2006 06:39:49 PM UTC

If I inherit a proctected frame can I then modfy it with out 'tainting' it?

Like adding another texture or text layer to it?

60

Iriel

< The Vigilance Commit… >

Silver Hand

4. Re: Guide to Secure Execution and Tainting  |  10/13/2006 06:44:46 PM UTC

Q u o t e:
If I inherit a proctected frame can I then modfy it with out 'tainting' it?

Like adding another texture or text layer to it?

The 'protection' of a protected frame only extends down towards its parent and anchors. You can add new children to the frame and do whatever you need to do with them.

UI and Macros Forum MVP - Understand GC!

60

Potillan

< Flawed >

Archimonde

5. Re: Guide to Secure Execution and Tainting  |  10/13/2006 06:47:19 PM UTC

Q u o t e:
The 'protection' of a protected frame only extends down towards its parent and anchors. You can add new children to the frame and do whatever you need to do with them.

Ok thanks (especially for understanding my kind of cryptic question hehe)

And thanks for the great write up.

60

Sabindeus

< Runehammer >

Smolderthorn

6. Re: Guide to Secure Execution and Tainting  |  10/13/2006 06:53:35 PM UTC

Is it possible to call the new secure functions from tainted code out of combat?

For example, if I wanted to use TargetUnit out of combat, would it silently fail, return/throw an error, or actually work?

http://www.curse-gaming.com/en/wow/addons-1996-1-turn-in.html

60

Iriel

< The Vigilance Commit… >

Silver Hand

7. Re: Guide to Secure Execution and Tainting  |  10/13/2006 06:55:06 PM UTC

Q u o t e:
Is it possible to call the new secure functions from tainted code out of combat?

For example, if I wanted to use TargetUnit out of combat, would it silently fail, return/throw an error, or actually work?

See the 2.0 changes thread for details of which can be called when. Targetting is off limits at all times, but casting spells will currently be allowed out of combat.

UI and Macros Forum MVP - Understand GC!

65

Helpinghand

< Dawn Breaker >

Gorefiend

8. Re: Guide to Secure Execution and Tainting  |  10/13/2006 07:59:38 PM UTC

Q u o t e:

See the 2.0 changes thread for details of which can be called when. Targetting is off limits at all times, but casting spells will currently be allowed out of combat.

Will mods such as WhisperCast still work in 2.0 then? They require the ability to target something and cast a spell? I wouldn't mind one bit if WhisperCast still worked, but only out of combat (in combat the mod would cease to function).

http://wow.blupp.net/item.php?id=338321

60

Leynna

< Insomniacs >

Stonemaul

9. Re: Guide to Secure Execution and Tainting  |  10/13/2006 08:22:43 PM UTC

Thanks Iriel. I really appreciate your hard work and dedication.

60

Iriel

< The Vigilance Commit… >

Silver Hand

10. Re: Guide to Secure Execution and Tainting  |  10/13/2006 08:27:42 PM UTC

Q u o t e:

Will mods such as WhisperCast still work in 2.0 then? They require the ability to target something and cast a spell? I wouldn't mind one bit if WhisperCast still worked, but only out of combat (in combat the mod would cease to function).

Out of combat you would likely be able to reconfigure an action button to cast on the appropriate target, though i'm not sure if that works reliably with non-unitID-targets.

UI and Macros Forum MVP - Understand GC!

60

Corpserie

< Unholy Tribunal >

Elune

11. Re: Guide to Secure Execution and Tainting  |  10/13/2006 08:49:31 PM UTC

I've been working on an add on for my guild to streamlinethe process of buffing a raid, that scans the raid and applies group buffs or cheap buffs to players or parties that need them. Upon first reading about the changes it seemed like this would be broken, but I'm kind of hopeful that it might work out of combat. Any ideas?

60

Maldivia

< Nova >

Sargeras

12. Re: Guide to Secure Execution and Tainting  |  10/14/2006 12:32:37 AM UTC

Q u o t e:
I've been working on an add on for my guild to streamlinethe process of buffing a raid, that scans the raid and applies group buffs or cheap buffs to players or parties that need them. Upon first reading about the changes it seemed like this would be broken, but I'm kind of hopeful that it might work out of combat. Any ideas?

It can work just fine out of combat.

Make a Button that inherits from SecureUnitButtonTemplate. Add a PreClick script, that, if you're out of combat, sets the necessary attributes to select spell and target -- and done. Something like:

button:SetScript("PreClick", function(self)

local unit, spell = getUnitAndSpellViaSomeLogic();

self:SetAttribute("type1", "spell");

self:SetAttribute("unit1", unit);

self:SetAttribute("spell1", spell);

end);

"Changing the interface art is fine. Everything else is off limits." -- slouken

60

Phayd

Scilla

13. Re: Guide to Secure Execution and Tainting  |  10/14/2006 01:29:00 AM UTC

If a protected frame (a) is anchored to another protected frame (b) and the size of (b) changes would that cause (a) to move to the new anchored position as expected? Obviously the size of (b) changing would be dependant on a secure unit frame header implementing dynamic resizing. My only concern here is simply keeping frames cleanly organized via anchors while in combat if and when the raid composition changes (either group arrangements or players join/leave the raid).

I'm hoping that we will also be given a secured raid frame header for creating frames that expand/collapse based on dynamic, user-defined unit sets that are not based off of taboo combat data but rather based off of data such as class, group, and name. Dynamic sets would be sets defined prior to combat that would be boolean combinations of those base sets. The dynamic sets would be updated and reflected in combat by the secured frame header and associated frames would resize accordingly. For example a valid set join by classes could be Warriors or Rogues. Another set of even # groups would expand and collapse as players are moved in and out of those groups.

To see what I'm after in action, please look at sets in RDX. I can live without sorting within individual sets and I can live without unit filters that are based off of taboo data for obvious reasons. I simply want the flexibility of lists to be securely defined prior to combat with the capacity demonstrated by RDX minus the parameters that are taboo (health,mana,debuffs,buffs,range,etc). And I want the cleanliness of RDX style frame resizing, anchoring, and filtering to remain a possibility as it saves me allot of screen space.

60

Maegril

< Children of the Phoe… >

14. Re: Guide to Secure Execution and Tainting  |  10/14/2006 02:52:47 AM UTC

Q u o t e:

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.

Can we get some type of better information about what "nor can its attributes be changed"? Does this mean we can't, after all, dynamically change color/alpha of a frame to indicate status?

60

Cogwheel

< Temple of Light >

Shadowsong

15. Re: Guide to Secure Execution and Tainting  |  10/14/2006 03:20:38 AM UTC

"Attributes" is the term used in XML for things like the following:

<Frame name="MyFrame" virtual="true">

the attributes are name & virtual. By "can't change attributes" it means we can't call the SetAttribute method on secure frames while in combat.

[ Post edited by Cogwheel ]

http://www.catb.org/~esr/faqs/smart-questions.html#before

Give a troll a macro, and you've fed him for a day.

Teach a troll to macro, and he'll stop bugging you to give him macros.

60

Iriel

< The Vigilance Commit… >

Silver Hand

16. Re: Guide to Secure Execution and Tainting  |  10/14/2006 03:34:20 AM UTC

Q u o t e:
If a protected frame (a) is anchored to another protected frame (b) and the size of (b) changes would that cause (a) to move to the new anchored position as expected? Obviously the size of (b) changing would be dependant on a secure unit frame header implementing dynamic resizing. My only concern here is simply keeping frames cleanly organized via anchors while in combat if and when the raid composition changes (either group arrangements or players join/leave the raid).

Yes. if the size of (b) CAN be changed, then everything updates as expected. The protection extends to anchor relative frames so even if (b) wasn't explicitly protected, it's protected as soon as (a) anchors to it.

Q u o t e:
I'm hoping that we will also be given a secured raid frame header for creating frames that expand/collapse based on dynamic, user-defined unit sets that are not based off of taboo combat data but rather based off of data such as class, group, and name.

Look at the raid header template as it emerges. There are limited filtering options, but hopefully they're sufficient for most uses. If there are specific needs that can be justified then try requesting them now, I'm not sure if the relevant parties are still making changes but it'd be worth a try. I dont believe boolean combinations are supported yet, though that kind of flexibility is an interesting idea, the trick is implementing it in a way that's useful, efficient, and secure.

As regards sizing and positioning, the members of one header group must be treated more or less interchangably, but raid independently managed header groups can be totally different.

UI and Macros Forum MVP - Understand GC!

60

Iriel

< The Vigilance Commit… >

Silver Hand

17. Re: Guide to Secure Execution and Tainting  |  10/14/2006 03:35:48 AM UTC

Q u o t e:

Can we get some type of better information about what "nor can its attributes be changed"? Does this mean we can't, after all, dynamically change color/alpha of a frame to indicate status?

Check the 2.0 changes thread, attributes are a new frame thing:

value = frame:GetAttribute("name")

frame:SetAttribute("name", value)

(The shared naming with XML attributes is coincidental)

UI and Macros Forum MVP - Understand GC!

60

Cogwheel

< Temple of Light >

Shadowsong

18. Re: Guide to Secure Execution and Tainting  |  10/14/2006 04:00:14 AM UTC

Q u o t e:
(The shared naming with XML attributes is coincidental)

Huh... for some reason I thought the SetAttribute() method was used to set the XML attributes.

Silly me

http://www.catb.org/~esr/faqs/smart-questions.html#before

Give a troll a macro, and you've fed him for a day.

Teach a troll to macro, and he'll stop bugging you to give him macros.

60

Phayd

Scilla

19. Re: Guide to Secure Execution and Tainting  |  10/14/2006 05:06:47 AM UTC

Q u o t e:
I dont believe boolean combinations are supported yet, though that kind of flexibility is an interesting idea, the trick is implementing it in a way that's useful, efficient, and secure.

The interesting thing about boolean combinations of sets is that the resulting sets are as secure as the sets they are built off of. The only set I suggested that isn't secure and already used by blizzard is the user defined list of names. That set can easily be secured by being defined prior to entering combat and would not be mutable while in combat. As long as the set definitions can only be defined out of combat, they can maintain the security and dynamic nature of the sets they are based off of.

1 . 2 . 3 . 4

Forum Nav :

WoW Technical SupportMac Technical SupportCustomer Service ForumWoW Realm StatusUI & Macros ForumBug Report Forum---------------------------------------Druid DiscussionRogue DiscussionPriest DiscussionHunter DiscussionShaman DiscussionWarrior DiscussionMage DiscussionPaladin DiscussionWarlock Discussion---------------------------------------WoW Professions DiscussionWoW PvP DiscussionWoW Quest DiscussionRealm ForumsBlizzard ArchiveWoW Off-topic DiscussionWoW SuggestionsWoW Guild RecruitmentWoW Guild RelationsWoW Role-PlayingWoW GeneralWoW Raids & DungeonsTest Realm ForumWoW Guide ForumWelcome to WoWWoW Battlegroup Forums

Online Privacy Policy
©2006 Blizzard Entertainment. All rights reserved.