yesterday I tried to install the new 8.0.24.0 player for IE6 and Firefox on
WinXP SP2.
1. Firefox-Plugin: Installs to c:\windows\system32\macro... but not to
c:\program files\mozilla firefox\plugins. So Firefox used still the 8.0.22.0
plugin and I had to copy the files manually from system32 to Firefox plugin
folder to get it updated. Installation of previous 8.0.22.0 did copy into the
proper folder.
2. IE6-Plugin: Switched user to Admin as plugin couldn't be installed without
admin rights. New 8.0.24.0 works when I'm logged in as admin. When I switch
back to restricted user the plugin doesn't work, IE shows the bar above that a
missing plugin needs to be installed (what cannot be done as restricted user).
Again, 8.0.22.0 installed and worked fine on the same config.
Anyone else tried the new plugin as a restricted user?
If I completely uninstall flash and delete the
c:\windows\system32\macromed\flash folder, give that general user admin rights,
log in as that general user and install flash, then the flash pages come in ok.
If after this install by the general user with admin rights logs out and I
remove admin rights from that general user and place him/her back with power
user rights; and that general user logs back in again, the flash pages now
still comes in ok!! The only difference here is that that general user
installed flash with admin rights to begin with before removing that general
user's admin rights. HOWEVER, other general users logging in with only power
user rights on the same machine will again get the same error when going to a
flash page!
HKEY_CLASSES_ROOT\CLSID\{D27CDB70-AE6D-11cf-96B8-444553540000}
HKEY_CLASSES_ROOT\CLSID\{D27CDB6E-AE6D-11cf-96B8-444553540000}
I have contacted Adobe (Macromedia) about this and wrote about it here,
with no response yet:
I have also removed Adobe from my Christmas list until further notice.
-- Chris Lundie
HKEY_CLASSES_ROOT\CLSID\{D27CDB6E-AE6D-11cf-96B8-444553540000}
Other ActiveX controls (e.g., RealPlayer) run perfectly well in these accounts
under Limited-User privileges, so I don't think this is a Windows issue despite
the fact that this occurred on Microsoft's "Update Tuesday". No major changes
were included in the latest round of their updates. What also bothers me is
that the "last-modified" date for flash8a.ocx is January 2, 2006. I wonder
just what has changed, if anything, other than the fact that Flash now is
useful just for Administrators. By the way, uninstalling Flash using the
program 'uninstall_flash_player.exe' and then reinstalling it had no effect.
The file information, and the behavior, remained the same.
As an amusing aside, I mused about killing the control until the issue was
resolved and looked at the ActiveX compatibility section. They apparently have
an incorrect Registry data type for the ActiveX Compatibility for Flash. I
show a REG_SZ entry for Flash; all of the other thousands of entries (mostly
killed controls) have DWORDs. Present entry:
"Compatibility Flags"="0"
It should be a DWORD, no? I.e.,
"Compatibility Flags"=dword:00000000
Mister J
All users must have read/write access to
c:\<winversion>\system32\macromed for Flash Player to work (doc'd in "
Common Macromedia Flash Player install issues", at
http://www.macromedia.com/cfusion/knowledgebase/index.cfm?id=tn_19166)
Beyond that I'm checking with Engineering to see how what the facts are
about limited user installs and I'll post something as soon as I have
more info..
Bentley Wolfe
Senior Support Engineer, Flash/Flash Player
*Macromedia, now a division of Adobe Systems
Got Firefox plugin installed in the proper folder by editing some registry
values with plugin paths (installed a beta nightly version of firefox by
extracting a zip rather than running an installer).
Operation depending upon the user doing the installation.
Macromedia's requirement to use a special tool to uninstall.
The idea occurred that someone might be altering Registry permissions. Well,
the following two keys fit the bill:
HKCR\CLSID\{D27CDB6E-AE6D-11cf-96B8-444553540000} Shockwave Flash Object
HKCR\CLSID\{D27CDB70-AE6D-11cf-96B8-444553540000} Macromedia Flash Factory
Object
For these two keys, and possibly for others that I have not discovered,
SetValue and Delete are being denied to everyone. I cannot "neutralize" these
permissions by exporting them, deleting the keys, and importing them back into
the Registry until I alter the permissions to remove the denial of SetValue and
Delete privileges. After having done just that, Flash works for all users,
even for the Guest account.
I am very reluctant to post directions on Registry modifications. Otherwise,
the first person who has non-standard privileges installed by an Administrator
will scream when I wreck their system. Mitigation instructions should come
from Adobe/Macromedia, not from forum users. I'm not sure just what motivated
Macromedia to do what they have done here, but it is not a bright idea.
Registry permissions are dangerous privileges. DON'T MESS WITH THEM.
If there are other keys that have such alterations, then I am going to request
that Macromedia kindly inform us. It is imperative that Macromedia repair the
damage done. They must also come up with a standard ActiveX control that can
be removed by the usual means. To this writer, "cementing" programs and
Registry entries is just one or two steps removed from dropping a rootkit into
the system.
Mister J
XP/SP2; IE6/SP2
HKEY_CLASSES_ROOT\CLSID\{1171A62F-05D2-11D1-83FC-00A0C9089C5A} FlashProp Class
HKEY_CLASSES_ROOT\TypeLib\{D27CDB6B-AE6D-11CF-96B8-444553540000} Flash TypeLib
Interesting that Shockwave {166B1BCA-3F9C-11CF-8075-444553540000} has normal
permissions, but Flash needs to be "locked" into the Registry. And the control
Flash8a.ocx is locked down. Of the four files in
C:\WINDOWS\SYSTEM32\Macromed\Flash, the Flash control is read-only. Looking at
it in a CMD window, dir/s/ar WINDOWS\SYSTEM32\Macromed shows: 2006-01-02
11:13 AM 1,443,464 Flash8a.ocx. Why the stealth? Good grief; dir/s/ar
WINDOWS\SYSTEM32\*.dll shows just 25 files out of a total of 4,837. And why
January 2 for a control released on March 14? With some difficulty, I rescued
the March 14 cabinet file from the Temp files and verified that the contents
are the same as what are now in the Macromed folder. Shame on me, but I didn't
check to see what had been in Macromed before doing the update, figuring that
Macromedia would be the last operation to mess up an installation. However,
the date of January 2 would seem to indicate that the control is the old one.
Kindly correct me if mistaken.
One is forced to ask the question, "Is the meat of the March 14 update simply
the lockdown of the Flash Registry keys?" If that is indeed the case, then
unlocking the keys in an attempt to get the control to work will simply revert
the control to the alleged vulnerable state. Lacking other answers, it may be
necessary to disable the control until this issue is resolved.
Mister J
XP/SP2; IE6/SP2
There is much more to it than that.
We are actively working on a solution for the restricted user
permissions problem. Should have more info on Friday..
Just a quick update to say that giving ONE reg key "read" (not full control)
permissions for "everyone" allowed me to install Flash in the user account, and
it works perfectly. The key is
HKEY_CLASSES_ROOT\CLSID\{D27CDB6E-AE6D-11cf-96B8-444553540000} .
However, I have NO idea if this increases vulnerability at all and so am still
looking forward to official word from MM. I only took this step because I am
doing the update for someone else, and will not have access to this computer
for long, and the friend is VERY computer phobic and will never (thank heaven)
go into the registry himself. So it was now or never, and he needed his Flash.
We are actively working on isolating this issue for an appropriate fix,
but I would like to address some of the concerns raised here about
registry and file permission changes introduced in this release. Per
the release notes:
http://www.macromedia.com/support/documentation/en/flashplayer/8/releasenotes.html#24
"The update to Flash Player 7 (7.0.63.0) and Flash Player 8 (8.0.24.0)
includes security enhancements described in Security Bulletin
APSB06-03, and also introduces additional version checking to the
installation process. Because older installers and controls do not
contain the new version checking logic, the Flash Player control is
locked upon installation. Starting with this update, installers and
uninstallers from Adobe are designed to work with this change, and
there is no impact to the end-user installation experience. Flash and
Flex developers may need to make slight modifications to their normal
methods of switching between player versions during testing to account
for this change."
This release includes the new version checking logic in addition to
fixing internally discovered vulnerabilities. Right now, it appears
that when admins configure the rights for restricted user profiles,
there is some issue with propagation of rights that apparently
overrides the settings of this particular registry key to block read
access.
Gracielaj's temporary workaround is fine until we fix the issue and
will not affect the vulnerability of the player. This change gives Read
access to the GUID for Flash Player which will allow Internet Explorer
to read the key and load the player for Restricted Users. Note: do not
give Write permissions to the key, as it may introduce vulnerabilities.
Technote: http://www.macromedia.com/go/624850b5
Thanks,
Emmy Huang
Product Manager, Flash Player
This issue it is a little sporadic, which is why we consider this issue
under investigation. We are actively working on isolating this issue
for an appropriate fix. Providing information on OS version, SP
versions, IE versions when reporting issues is extremely helpful to us
for this reason.
best,
Emmy
Product Manager, Flash Player
Bentley Wolfe posted a workaround technote:
http://www.macromedia.com/go/624850b5 . Reading the referenced technical note
leaves me with as many questions as answers.
A check of the technote's Registry keys shows that the very last one,
HKLM\SOFTWARE\ ... \Uninstall\{436EE5F2-71F0-4738-B8E7-93741EF4828F}, is not in
my system. Neither it nor the GUID {436EE5F2-71F0-4738-B8E7-93741EF4828F} has
EVER been, according to past Registry backup files. But as a consolation
prize, HKLM\SOFTWARE\ ... \Uninstall\ShockwaveFlash is present. And the
statement, "...They will also need write access privileges to the following
directory: C:/Windows/System 32/Macromed/" also doesn't correspond with what
exists in this machine. Flash runs perfectly well here even though USER write
privileges do not exist for the directory. And what is being written? Even on
the occasions when I run as an Administrator on the Internet, visiting trusted
sites having Flash, there appears to be nothing written to any folder or
subfolder in C:/Windows/System 32/Macromed. For the entire year 2006 to date,
other than the March 15 update, only Shockwave.log has been modified -- on
January 6.
Mister J
XP/SP2; IE6/SP2
Bentley, thank you for officially posting the workaround we'd found already,
but just one more note: for those on Win2k machines, there is no "right click,
choose permissions" option. Any thoughts for Win2k machines?
And hopefully, from here on in, Adobe will a) seriously consider the
security-related phenomena of savvy users running as user rather than admin. on
the net and b) beta test these updates under more real-world conditions.
And please understand that it is critical for most of us that anything we
install on our own or client computers can be easily uninstalled, which is
apparently not necessarily the case with this. Would love this to be addressed
as well.
Thanks again for the response; have passed along the link to the tech note.
Gracie:
On Windows 2000, there is a difference between 'REGEDIT' and 'REGEDT32'. The
latter (regedt32) will give you more capabilities than 'regedit'. On XP, the
programs are one and the same.
Mister J
XP/SP2; IE6/SP2
Why am I posting on Saturday? I need to have my head examined....
We appreciate the concern, really. Rest assured that this situation is
being taken very, very seriously.
For Win2K, use regsvr32. As the technote mentions, our target for this
is XP, which is why we didn't mention that. If I see a lot of requests
I'll add text about Win2k...
Keep in mind this is an interim workaround while we develop a more
complete solution that won't require any manual editing. That complete
solution should handle your uninstall question.
In a perfect world there would be no errors. Then I'd be unemployed....
I, and hopefully all others, appreciate your participation in this matter.
Must be a tough Saturday morning indeed. regsvr32 registers or unregisters (/u
option) an ActiveX control. You do mean regedt32, I believe?
Mister J
For Win2K, use regsvr32.
I sympathize, Bentley, as I'm posting on a Saturday too :). I'd love to know
if the fix for Win2k is the same, just using REGEDT32 (I assume you meant that
and not Regsvr...). I'll give it a try when I can get back to the client
laptop.
I DO believe y'all are taking this seriously, and appreciate the help; hope
you understand our frustration that this very obvious flaw wasn't picked up
before release. We're all in this together, and certainly don't want you out of
a job, while still hoping for bug-free software :). Have a good weekend.
What's written in
http://www.macromedia.com/cfusion/knowledgebase/index.cfm?id=624850b5 isn't
actually enough. I had to do to the same thing with:
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\TypeLib\{D27CDB6B-AE6D-11CF-96B8-44455354000
0},
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{1171A62F-05D2-11D1-83FC-00A0C9089C5A}
,
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{D27CDB6E-AE6D-11cf-96B8-444553540000}
keys
Hope, this will help someone.
Macromedia, thanks for the 2 lost hours :(
Btw, why I cannot make:
var xmlhttp = WScript.CreateObject("FlashFactory.FlashFactory");
with windows scripting host?
the same time this one work perfectly:
var xmlhttp = WScript.CreateObject("ShockwaveFlash.ShockwaveFlash");
Any idea when the "complete solution" will be made available?
I was sober, honest. Of course i meant regedt32...
> If the concern were being taken "very, very seriously" as you suggest, you would not be complaining about posting on a Saturday.
Well, I complain a lot. Part of my nature...
> Any idea when the "complete solution" will be made available?
I do not have any further information that I can announce at this point.
Does this "lock-down" mean that you can never delete/move/etc. the flash8a.ocx
file (without going through the registry)? Before I reinstalled flash, I moved
the existing flash folder onto my desktop so I'd have a copy of it just in
case. After reinstall, I realized that the file "flash8a.ocx" that's in my
desktop folder cannot be erased and it cannot be changed from it's current
"readonly" state (again, without going through registry). Which means now I
have a flash folder on my desktop that has no purpose being there.
I know, minor details, BUT, this just points out the obvious (dare I say
blatant) lack of real-world testing done on this seemingly critical security
update from adobe/macromedia; and I've always placed adobe/macromedia in high
regards when it comes to their products. I would think a single hour of
testing by a single person would have concluded at least half of the problems
we users are now facing. My best guest is that the program was written...and
it was released with NO testing at all. This brings the business concept of
putting beta products on the market to have users "pay" to do the testing and
then have them pay again for the upgrades to another level! Granted, this
flash update is Free, but it becomes very costly when we the users cannot get
our work done!
ps, give the Adobe's Bentley Wolfe here a break, let's not kill the messenger
who may be our only link to Adobe/Macromedia...
...this just points out the obvious (dare I say blatant) lack of real-world
testing...
...give the Adobe's Bentley Wolfe here a break, let's not kill the messenger
who may be our only link to Adobe/Macromedia...
Wingtong:
Regarding the first item, I used the term "lock down" loosely to describe the
read-only status given to the referenced Adobe folder. Microsoft doesn't even
do this to its own files in WINDOWS\SYSTEM32 with the exception of a few files.
You don't need to go through the Registry to delete read-only files and
folders. One can, with Administrator privileges, simply change the file or
folder properties by right-clicking its name and then left-clicking
"Properties". Under the "General" tab, the file/folder attributes will show
near the bottom of the window. Clear the "Read only" button and click OK. If
you do this to a folder, you may get a popup window asking if this is to be
applied to subfolders and files. In your case, with the unwanted folder, apply
it to all. I've seen this work and fail. For the latter, attempt to change
the attributes of individual files, deleting afterwards as you go. This should
be simple enough; the Flash folder has just 4 files in my system. If you still
have trouble, post back.
Now as for flash8a.ocx, one should not simply delete it. ActiveX controls, if
just deleted, leave broken paths in the Registry. There are several methods
used to clean them up. The preferred way is to use Add/Remove Programs if the
control does show there, and in fact Flash does have an entry in that list.
Unfortunately, Flash cannot be removed by that method per
http://www.macromedia.com/cfusion/knowledgebase/index.cfm?id=tn_14157 . As
described there, you now need to download and run uninstall_flash_player.exe.
For the record, other ActiveX removal methods include using the right-click
and "Remove" option in the C:\Downloaded Program Files folder, using regsvr32
/u ---.dll and then Delete for dll-based controls, and, as a good last-resort,
using the capabilities in the ever-popular HijackThis program.
Regarding your other two quoted comments, this writer fully agrees with the
testing issue. I always felt that Flash was probably the finest example of an
ActiveX control -- safe, fairly lean on resource requirements (compared with
QuickTime, for example), and functional. After this blows over, it probably
will revert back to that status. But, to Adobe/Macromedia, test the darned
thing before you release it. And find a fix that requires neither a Registry
"hack" nor an uninstaller. Both are downright ugly, and potentially
troublesome as evidenced by this latest issue. And, yes, kudos to Bentley
Wolfe for standing in the line of fire and keeping us informed. Keep it up,
Bentley!
Mister J
...by the way, did we scare away our Adobe contact Bentley? ...must be a
bigger more complex issue for Adobe than we may think?
Before you try complicated and/or desperate measures to delete the unwanted
folder, try this little trick. Just drag it from your desktop into
Macromedia's Flash folder at C:\WINDOWS\SYSTEM32\Macromed\Flash. If your
system is like mine, you then will have four files along with the unwanted
folder. The next time you uninstall Flash prior to the next update (hopefully
very soon), the uninstaller should remove everything inside the Flash folder,
including the junk subfolder. Let it clean up its own mess.
Mister J