recent security patch breaks desktop.ini CLSID folder-app association and custom icon

  • Thread starter Thread starter asinning
  • Start date Start date
A

asinning

I posted this at winxp/general last week but haven't gotten any
replies. Thanks for any insight!

We (the software company I work for) have been using a desktop.ini file
to (1) create a unique icon for the "library folders" used with our
application and (2) to associate these folders with our application so
that double-clicking on the folder launches our application and lets
our application open the library.

The desktop.in just looks like this:

[.ShellClassInfo]
ConfirmFileOp=0
CLSID={our-class-id}

And then in the registry:

To assign an icon to the folder:

Key Name:
HKEY_CLASSES_ROOT\CLSID\{our-class-id}\DefaultIcon
Class Name: <NO CLASS>
Value 0
Name: <NO NAME>
Type: REG_SZ
Data: path to our icon

To associate the folder with our application:

Key Name:
HKEY_CLASSES_ROOT\CLSID\{our-class-id}\Shell\Open\command
Class Name: <NO CLASS>
Value 0
Name: <NO NAME>
Type: REG_SZ
Data: "path to our application" "%1"

Unfortunately, a recent XP security patch has broken this.
According to <http://secunia.com/advisories/11633/>:

"The problem is that "desktop.ini" files may contain CLSID references
to arbitrary executables in the "[.ShellClassInfo]" section. This can
be exploited to execute arbitrary files with another user's privileges
when the user browses a folder containing a malicious "desktop.ini"
file."

Does anybody know if there might be another way to accomplish this? I
spent a lot of time making this work, and now it's broke!

Thanks
 
asinning said:
I posted this at winxp/general last week but haven't gotten any
replies. Thanks for any insight!

We (the software company I work for) have been using a desktop.ini file
to (1) create a unique icon for the "library folders" used with our
application and (2) to associate these folders with our application so
that double-clicking on the folder launches our application and lets
our application open the library.

The desktop.in just looks like this:

[.ShellClassInfo]
ConfirmFileOp=0
CLSID={our-class-id}

And then in the registry:

To assign an icon to the folder:

Key Name:
HKEY_CLASSES_ROOT\CLSID\{our-class-id}\DefaultIcon
Class Name: <NO CLASS>
Value 0
Name: <NO NAME>
Type: REG_SZ
Data: path to our icon

To associate the folder with our application:

Key Name:
HKEY_CLASSES_ROOT\CLSID\{our-class-id}\Shell\Open\command
Class Name: <NO CLASS>
Value 0
Name: <NO NAME>
Type: REG_SZ
Data: "path to our application" "%1"

Unfortunately, a recent XP security patch has broken this.
According to <http://secunia.com/advisories/11633/>:

"The problem is that "desktop.ini" files may contain CLSID references
to arbitrary executables in the "[.ShellClassInfo]" section. This can
be exploited to execute arbitrary files with another user's privileges
when the user browses a folder containing a malicious "desktop.ini"
file."

Does anybody know if there might be another way to accomplish this? I
spent a lot of time making this work, and now it's broke!

Thanks
Click to expand...


It's not broke, it is a way to exploit the safety and security of the
Operating System, so MS plugged it. Just because it was something you/your
company were using for legitimate purposes, doesn't make it any less of a
security threat.
I would suggest posting this in some of the MS development newsgroups,
there are litterally hundreds, but make sure it deals with the language and
development tool you are using, i.e. Visual Studio dotNET or the old Visual
Studio, you may even try some of the scripting newsgroups, as they may be
able to give you ideas on how to accomplish different alternatives.
P.S. I feel for you, as I too wrote an ingenious way to do something, but
as it turned out, it too was a safety/security threat that MS needed to
plug - I don't hold malice or grudge towards MS for making our systems safer
and more secure, but it is dishearting when you have to re-engineer
something and spending time on it when you hadn't planned on it.
 
It's not broke, it is a way to exploit the safety and security of the
Operating System, so MS plugged it. Just because it was something you/your
company were using for legitimate purposes, doesn't make it any less of a
security threat.
Click to expand...

I have changed the subject to "recent security patch _prevnets_
desktop.ini CLSID folder-app association and custom icon" and reposted
at both microsoft.public.dotnet.security and
microsoft.public.dotnet.scripting.
 
I've recently posted about this, I believe, in this very newsgroup (I
haven't checked yet whether I got any reply or not).

In my case, my custom partition icons (set up through an AUTORUN.INF file
like the following) don't work anymore:

[AutoRun]
Icon=someicon.ico

However, my custom folder icons, set through desktop.ini files, still do.
My desktop.ini files are much simpler than yours though:

[.ShellClassInfo]
IconFile=someicon.ico


Admiral Q: is this idea of a security threat your own speculation, or is
this actually documented by MS somewhere?
 
Admiral Q: is this idea of a security threat your own speculation, or is
this actually documented by MS somewhere?
Click to expand...

Never mind this part, next time I'll read the *entire* message...

OTOH, I don't see how making a reference to an .ICO file poses a security
threat...unless the OS code itself to extract an icon from a resource is
vulnerable...in which case that code should be fixed rather than disabled
altogether...
 
Homer: Yes, having a custom icon using the IconFile parameter is very
well documented in dozens of places all over the web and continues to
work very well.

I am NOT using that method. My objective is to have the folder act
essentially like a file, and to have that folder associated with an
application. Previonsly, the way to do this was using a CLSID and
putting the icon and open comman in the registry for that CLSID. This
technique is not well documented, and alas, no longer works.
 
asinning said:
I posted this at winxp/general last week but haven't gotten any
replies. Thanks for any insight!

We (the software company I work for) have been using a desktop.ini file
to (1) create a unique icon for the "library folders" used with our
application and (2) to associate these folders with our application so
that double-clicking on the folder launches our application and lets
our application open the library.


Unfortunately, a recent XP security patch has broken this.
According to <http://secunia.com/advisories/11633/>:
Click to expand...

First things first, find and beat up Roozbeh Afrasiabi for reporting it. ;D

Does anybody know if there might be another way to accomplish this? I
spent a lot of time making this work, and now it's broke!
Click to expand...

Your best bet here is to look at how Windows does it itself. Windows has several such folders with desktop.ini files and the update
has not broken those. You can take a look at how Windows manages to "work around" the patch and follow suit. Take a look at the
desktop.ini files in "\Recycled", "\Windows\Fonts", "\Windows\Downloaded Program Files", "My Documents", and so on (pretty much any
folder that has an icon). See how they do it, maybe you can replicate it (they use DLLs for the shell-extension instead of a
straight-up app so maybe shell-extensions are still allowed and only apps are prevented.) Try using the UICLSID tag instead of
CLSID, maybe the patch doesn't account for that (yet).



Of course what may be happening is that the patch prevents 3rd party apps from using this and makes an exception for Windows' own
folders, in which case you may want to find others whose apps broke from this and start a petition; this would be just like the
anti-trust thing they went through a while back, so they may be willing to work something out.



HTH
 
Although I have not been able to fully resolve this issue, I have found
a viable work around.

First some background: The really GREAT thing about putting a clsid in
the desktop.ini file of a a folder is that you can actually get the
folder to look and act like a file in the standard Windos File Open /
File Save As dialog boxe. So, if you give the custom folder a special
extension (in our case "GSPLF") and you specify in your File Open/Save
dialog command the filter "*.GSPLF" then these folders will not only be
filtered, they will actually act file files. What I mean is that when
the user selects one of these folders in the the standard File Open
dialog boxes, rather than the dialog drilling down into these folders,
the dialog box will return the path to the folder to function that
called the Open box. This is extremely important from a UI standpoint.

I have found a work-around that manages to preserve the above
functionality.

What I have lost is the functionality where the user can double-click
on the FOLDER within Explorer and have the folder associated with the
appropriate application by way of the restistry setting
"Shell\Open\command" -> application-path %1.

Now, when I double-click on the folder within Explorer, the folder is
simply opened. Howerver, I now have a file within this folder called
"Librarey Opener.gsl" and I have the extension .gsl associated with my
application.

Here is the fix: I had to complete remove the restistry setting
"Shell\Open\command" for the CLSID in order to get the folder to behave
like a file in the File Open dialog box. Also, without removing the
restistry setting "Shell\Open\command" the custom folder icon would NOT
be displayed. Whatever MS did to patch this threat, it seems that they
made a rule, NO Shell\Open\Commands allowed for CLSIDs. If you include
a Shell\Open\Command, the CLSID will be ignored!!!
 
I just have to say ... I am so impressed that you guys can actually
understand what you are talking about! If I had my life to do over
again, I think I'd like to be a computer programmer.

Awaiting your responses with baited breath, I remain, yours truly,

<*(((>< ~~~
 
asinning said:
Here is the fix: I had to complete remove the restistry setting
"Shell\Open\command" for the CLSID in order to get the folder to behave
like a file in the File Open dialog box. Also, without removing the
restistry setting "Shell\Open\command" the custom folder icon would NOT
be displayed. Whatever MS did to patch this threat, it seems that they
made a rule, NO Shell\Open\Commands allowed for CLSIDs. If you include
a Shell\Open\Command, the CLSID will be ignored!!!
Click to expand...


Here's another thought; does your app use DDE? Perhaps only straight file interactions are limited and you can still use the Open
key if it works through DDE.
 
Alec said:
Here's another thought; does your app use DDE? Perhaps only straight file interactions are limited and you can still use the Open
key if it works through DDE.
Click to expand...

No it doesn't. It's written in Director. But with DDE, wouldn't the
application have to be running in the first place in order to capture
the data from DDE, or am I missing something? How would DDE be able to
_launch_ the app in the first place?

Thanks.
 
Back
Top