The scenario is that a user browses to an infected website, which causes Flash embedded in her browser to store malware that can then be loaded into a different Flash session.
How exactly (does it get loaded into a different session)? Where exactly is the malware stored?
Flash is able to cache downloaded data ("global storage"); see
http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager03.html for your Flash player's current setting. I don't know where it caches it, or what cross-session or cross-domain controls (if any) Flash might use to restrict when such data might be used. Also, even if Flash currently has such controls, and they're bug-free, a Flash update could break them.
Basically, embedding another software package within Avast is -- for security purposes -- like inviting members of that package's development team onto Alwil's staff. Indeed, it could be worse than that, because the other development team might be able to update its product -- and thus introduce something new into Avast's security perimeter -- without even consulting Avast's team.
BTW, I don't want it to seem like I'm singling out Avast here. Very many packages have similar vulnerabilities.
Under 4.8, the Avast GUI runs within the ashdisp.exe process, which runs under an administrative account with, among other things, the BUILTIN\Administrators group SID enabled.
OK, correction - the GUI runs under whoever is logged on, just like ashDisp.exe in avast! 4. So yes, if you log on as an administrator, it runs under your account.
However, if you're logged on as an administrator and your browser gets infected, you're screwed anyway.
It's certainly true that browsing in an admin account is asking to be infected. However, just because ashdisp runs in an administrative account doesn't mean that your browser does. I, for example, always run browsers in an unprivileged account, and I often urge others to do the same.
Also, SeImpersonatePrivilege and apparently SeLoadDriverPrivilege (!) are enabled. I don't know about 5.x, which I haven't installed. Does it disable the administrative group SIDs and/or run ashdisp in a non-admin account? What privileges does it leave enabled?
Privileges are associated with the particular account - whether they're enabled or not is rather irrelevant (= enabling a privilege granted to your account is just a few API calls, anybody can do that).
It's more subtle than that. A program running under, say, "administrator" can create a token that restricts certain privileges. It can then CreateProcess a process using that token, but running under the same account, that then is not able to enable the restricted privileges. See the section on "dropmyrights" in
http://technet.microsoft.com/en-us/library/bb456992.aspx for more on this technique.
In any case, if the ashdisp process has certain privileges and/or privileged SIDs in its access token, and the embedded Flash that it runs becomes compromised, the attacker can use the resulting rights to infect the system.
