Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.basic.visual.misc > #1823 > unrolled thread

mscomctl.ocx and comctl32.ocx invoking third party executables?

Back to article view | Back to comp.lang.basic.visual.misc

Contents

  mscomctl.ocx and comctl32.ocx invoking third party executables? Lars Uffmann <aral@nurfuerspam.de> - 2011-02-03 15:53 +0100
    Re: mscomctl.ocx and comctl32.ocx invoking third party executables? "Mayayana" <mayayana@invalid.nospam> - 2011-02-04 09:35 -0500
    Re: mscomctl.ocx and comctl32.ocx invoking third party executables? Lars Uffmann <aral@nurfuerspam.de> - 2011-02-04 15:04 +0100
    Re: mscomctl.ocx and comctl32.ocx invoking third party executables? "Mayayana" <mayayana@invalid.nospam> - 2011-02-03 12:03 -0500
    Re: mscomctl.ocx and comctl32.ocx invoking third party executables? GS <gs@somewhere.net> - 2011-02-04 12:44 -0500
    Re: mscomctl.ocx and comctl32.ocx invoking third party executables? Lars Uffmann <aral@nurfuerspam.de> - 2011-02-04 15:19 +0100
      Re: mscomctl.ocx and comctl32.ocx invoking third party executables? "Nobody" <nobody@nobody.com> - 2011-02-04 10:05 -0500
    Re: mscomctl.ocx and comctl32.ocx invoking third party executables? "Nobody" <nobody@nobody.com> - 2011-02-04 02:58 -0500
    Re: mscomctl.ocx and comctl32.ocx invoking third party executables? GS <gs@somewhere.net> - 2011-02-03 14:22 -0500
      Re: mscomctl.ocx and comctl32.ocx invoking third party executables? Lars Uffmann <aral@nurfuerspam.de> - 2011-02-04 15:16 +0100
    Re: mscomctl.ocx and comctl32.ocx invoking third party executables? Lars Uffmann <aral@nurfuerspam.de> - 2011-02-03 17:40 +0100
    Re: mscomctl.ocx and comctl32.ocx invoking third party executables? GS <gs@somewhere.net> - 2011-02-03 11:11 -0500

#1823 — mscomctl.ocx and comctl32.ocx invoking third party executables?

Hey everyone!

I stumbled upon this behaviour which has me somewhat concerned about 
possible exploits:

OS: - WinXP Professional SP3 english
     - security patches up to date as of 2011-02-03

Office Version: 2003

When inserting any ActiveX control contained in either mscomctl.ocx or 
comctl32.ocx into an office document, the installer of a proprietary 
software, that I sadly can not share (as much as I would like to have 
someone reproduce this issue) is invoked.

The installer pops up with a "reconfiguring ..." dialog, not allowing 
the user any options other than to cancel the process. After that 
(aborting or letting it finish), the ActiveX control is inserted into 
the document and behaves as expected.

This usually happens twice, after which the control behaves as expected 
without invoking that installer. Some times the installer is invoked 
twice in a row upon one insertion of ActiveX control, sometimes it 
happens a few more times - but mostly the aforementioned two times.

If the window loses focus (does not work with alt-tabbing, does work 
with e.g. launching task manager or windows explorer and switching back 
to the office application), the unwanted behaviour returns.

The comctl32.ocx on a standard windows xp (SP3) will complain that it's 
not licensed properly and not insert the ActiveX component selected, 
however, it will still induce the unwanted behaviour of invoking the 
third party software installer.

I have checked the file version of mscomctl.ocx before vs. after 
installation of that third party software. The md5sum stays the same. I 
take that to mean that it is not modified by the installation.

Reproducible with: Microsoft ProgressBar Control 6.0 (SP4), also with 
ListView, ImageList and TreeView as well as a couple others, tested in 
MS Word, Access, Excel

NOT reproduciple in MS Powerpoint!

***Now my question:*** Can anyone list the means by which an ActiveX 
control can invoke some third party software upon first time being loaded?

Given that it does not know about the third party software (and no 
dependency), and that this is completely unwanted behaviour, I would 
like someone with more understanding than I have to tell me whether this 
means that there is a hook in that common control library that will 
allow unwanted execution of code, or only installed code, or not at all.

Thank you!

    Lars

[toc] | [next] | [standalone]

#1827

| >   Why are you protecting the maker of buggy software?
|
| Legal issues. Contractual bindings.
|

  That's a very strange contract that doesn't allow you
to talk about the product. ...But maybe not so strange
in the tech. world, where companies are always pushing
the limits of legality and common sense.

| Can you elaborate on your suspicion of different
| versions and what SxS functionality means?
|
   I don't want to send you on a wild goose chase.
I don't know much about SxS. It stands for "side by
side". The basic idea is that different software can
use different versions of libraries without conflict,
through SxS. I think it involves an accomodation to
register separate versions of COM libraries in XP+.
I really don't know whether that might be related to
the problem you're having, though. Just a thought.

   Another thought: Does the 3rd-party software from
FascistCo install via Windows Installer (.msi file)?
If so, that can do odd things. I've seen people
complain about installs that get corrupt, where the
installer repeatedly tries to run. Again, I don't know
enough to be of help, but if it seems worth checking
out you could try asking in an MSI group. There's
microsoft.public.platformsdk.msi, which is the busiest,
but I'm not sure how busy it is lately. I think that
the Microsoft devotees/MVPs have been pressured not
to use Usenet anymore. They've mostly disappeared
from the various groups since MS started their web
forums. There's probably a web forum for MSI, but I
don't know the URL. 

[toc] | [prev] | [next] | [standalone]

#1830

Mayayana wrote:
>   Why are you protecting the maker of buggy software?

Legal issues. Contractual bindings.

> If you can't say the details of the problem then how
> can anyone help?

I did say the details, I just left out one part, and it seems that 
people were indeed able to give helpful information nevertheless.

>    I wonder if the issue might be connected with different
> versions and the SxS functionality, but I really don't
> know. Just a wild guess. You might have better luck
> in an MS Office VBA group. VB and VBA are not exactly
> the same thing.

Nope, but with regards to the use of references and ActiveX objects they 
are very similar. Can you elaborate on your suspicion of different 
versions and what SxS functionality means?

Thanks,

   Lars

[toc] | [prev] | [next] | [standalone]

#1843

  Why are you protecting the maker of buggy software?
If you can't say the details of the problem then how
can anyone help?

   You just want to know how ProgramX can know
that you've loaded a control? Is ProgramX an Office
add-in? If not then it at least seems to be running.
Why is it running?

   I wonder if the issue might be connected with different
versions and the SxS functionality, but I really don't
know. Just a wild guess. You might have better luck
in an MS Office VBA group. VB and VBA are not exactly
the same thing.


| >
| > First thing you need to understand is that ANY MS Office project that
| > uses either of these controls needs to have a reference set to them in
| > the VBE (Visual Basic Editor).
|
| I do not have the feeling that you fully understood my post. The MS
| Windows Common Controls are properly registered with the MS Office 2003
| installation. And if they weren't, the project would be complaining
| about the ActiveX control being unknown/not found.
|
| But to be fair, you got me one step further: The component registration
| (reference creation) happens automatically, when the Common Control
| (e.g. ProgressBar) is inserted into the document. That is - if the
| object is not contained within the already referenced libraries/object
| files. Apparently this automatic referencing browses through available
| object files and finds some of my third-party software also. A call to
| these files then seems to invoke the installer. At least that is my
| current understanding of the problem.
|
| Still - why referencing a certain ActiveX where the object file is known
| would invoke other ActiveX object code is beyond me...
|
| > Also, the controls must be installed and properly registered on the
| > target machine the MSO project runs on. That means if your project will
| > be used on Vista OS or higher you'll have to distribute and register
| > these controls on that machine. This also means you'll have to develop
| > your project on a machine that has these OCXs properly installed.
|
| I don't understand what that has to do with the topic...? I am not
| trying to develop an office project, I am observing a strange/unwanted
| behaviour of an ActiveX control in office... And trying to find the cause.
|
| Cheers,
|
|   Lars 

[toc] | [prev] | [next] | [standalone]

#1851

It happens that Lars Uffmann formulated :
> GS wrote:
>> Well, whether you accept this or not, once you start adding non-office 
>> controls to an office doc YOU ARE building an office project.
>
> Whatever you feel comfortable calling it...
>
>> Also, any ActiveX control that is not part of the standard office controls 
>> should be referenced in the VBE so the MSO host app doesn't have to go 
>> through all this hooplah you're complaining about.
>
> The components in question are part of the "Microsoft Windows Common Controls 
> 6.0 (SP6)" - and I just tried it: added the reference to this (mscomctl.ocx) 
> to the project first, then inserted the ProgressBar - it still starts the 
> "hooplah" :(

Try using v5.0 instead. Seems I recall something buggy about v6.0 with 
Excel VBA. Can't remember exactly what it was but I use v5.0 and have 
no problems.

>
>
>> Setting the reference to the appropriate lib obviates this 'automatic' 
>> action you speak of.
>
> Sadly that did not work. I wonder if there is an option to turn this 
> behaviour off for MS Office... I believe - since the library is not normally 
> listed within the available references - windows starts a file search and 
> "asks" each file available to it whether it has that control the user is 
> trying to insert into his project. And calling that method for one of the 
> libraries of my third party software invokes its installer (which is poor 
> programming by the third party).
>
>> situations, I've never had the behavior you speak of happen to me nor to 
>> any of my users.
>
> Are you sure? Because - without that particular software installed, it 
> "seems" normal here also - yet I am pretty sure the unwanted behaviour of 
> office is that it searches other libaries for the object in question, even 
> though it has a valid reference. And this third party s/w I have here merely 
> adds a poor program behaviour that *shows* this unwanted behaviour of the 
> reference manager...

Absolutely sure! But thn, as mentioned, I use v5.0

>
>> Maybe, as Mayayana suggested, you should ask for help in a VBA group.
>
> I am pretty sure that this problem is caused by the references management, 
> which (like the VBA editor) has been shared between VB and VBA since office 
> 2k or 2k3 believe(?)...
>
> I could install regular VB and see if the behaviour is reproducible with that 
> also. Maybe will do that.

I use VB6 for COMAddins and v6.0 works fine there. I'm sure the problem 
is with MSO VBA (as far as I can recall), and so is why you should ask 
in an Office group.

>
> Cheers,
>
>    Lars

-- 
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc

[toc] | [prev] | [next] | [standalone]

#1852

Nobody wrote:
> The OCX's don't invoke any third party software. It's Windows Installer 
> which monitors certain registry keys and checks if they have been modified 
> or deleted and attempts to "repair" the installation. It's generally best to 
> insert the CD and let it finish.

Won't work. On some systems it finishes and does the same behaviour next 
time. On at least one other system it hangs in an endless loop. But that 
is not the problem I wanted to analyze here.

> Sometimes this is caused by a buggy installation script, so you need to ask the software vendor who's installer 
> being invoked to fix their installation script.

Yes I will do that to address one part of the problem.


To summarize: I believe so far that the "threat" with this (installer?) 
problem is minor, because it can only invoke executables linked to 
software that has been installed already anyways.

But that the reference manager (or installer) would do that even when it 
does not *need* to search for an object, is beyond me...

Best Regards,

   Lars

[toc] | [prev] | [next] | [standalone]

#1859

"Lars Uffmann" <aral@nurfuerspam.de> wrote in message 
news:8r2g3fF8qlU2@mid.dfncis.de...
> Nobody wrote:
>> The OCX's don't invoke any third party software. It's Windows Installer 
>> which monitors certain registry keys and checks if they have been 
>> modified or deleted and attempts to "repair" the installation. It's 
>> generally best to insert the CD and let it finish.
>
> Won't work. On some systems it finishes and does the same behaviour next 
> time. On at least one other system it hangs in an endless loop. But that 
> is not the problem I wanted to analyze here.
>
>> Sometimes this is caused by a buggy installation script, so you need to 
>> ask the software vendor who's installer being invoked to fix their 
>> installation script.
>
> Yes I will do that to address one part of the problem.
>
>
> To summarize: I believe so far that the "threat" with this (installer?) 
> problem is minor, because it can only invoke executables linked to 
> software that has been installed already anyways.
>
> But that the reference manager (or installer) would do that even when it 
> does not *need* to search for an object, is beyond me...

Don't feel bad. Windows Installer is running all the time, and it's just 
doing what it's been told to do. It has a long learning curve, even 
Microsoft doesn't seem to know how to use it. Their Office product 
installation script is buggy that it shows up when other applications that 
have nothing to do with Office run. Example:

Windows Installer prompts you for an Office 2000 CD, or you receive an 
"Error 1706" error message after you start a program that uses the 
Mscomctl.ocx file
http://support.microsoft.com/kb/298385

OFF2000: Windows Installer Appears Every Time a Program Is Started
http://support.microsoft.com/kb/265194

"Windows Installer" message appears every time that you start the 
Lithuanian, the Croatian, the Estonian, or the Ukrainian language version of 
Access 2002
http://support.microsoft.com/kb/842310


One common example is that the script tells Windows Installer to auto repair 
the installation if registry keys are missing, but provides an HKCU key 
instead of HKLM, so if a different user than the installer logs on, the 
value is missing, and Windows Installer attempts the repair. If the software 
offers you a choice between installing for all users, or just you, then try 
for all users.

Although OCX files are generally registered in HKLM, it's possible to 
install them per user by using HKCU. When COM tries to load the OCX, HKCU 
has precedence and this is when Windows Installer sees that the value is 
missing, even though it's in HKLM, because one software incorrectly told it 
told it that the value is supposed to be in HKCU.

[toc] | [prev] | [next] | [standalone]

#1872

"Lars Uffmann" <aral@nurfuerspam.de> wrote in message 
news:8qvtngFppsU1@mid.dfncis.de...
> The installer pops up with a "reconfiguring ..." dialog, not allowing the 
> user any options other than to cancel the process. After that (aborting or 
> letting it finish), the ActiveX control is inserted into the document and 
> behaves as expected.

The OCX's don't invoke any third party software. It's Windows Installer 
which monitors certain registry keys and checks if they have been modified 
or deleted and attempts to "repair" the installation. It's generally best to 
insert the CD and let it finish. Sometimes this is caused by a buggy 
installation script, so you need to ask the software vendor who's installer 
being invoked to fix their installation script.

[toc] | [prev] | [next] | [standalone]

#1874

Lars Uffmann presented the following explanation :
> GS wrote:
>> After serious thinking Lars Uffmann wrote :
>>> [Fullquote removed]
>> 
>> First thing you need to understand is that ANY MS Office project that uses 
>> either of these controls needs to have a reference set to them in the VBE 
>> (Visual Basic Editor).
>
> I do not have the feeling that you fully understood my post. The MS Windows 
> Common Controls are properly registered with the MS Office 2003 installation. 
> And if they weren't, the project would be complaining about the ActiveX 
> control being unknown/not found.
>
> But to be fair, you got me one step further: The component registration 
> (reference creation) happens automatically, when the Common Control (e.g. 
> ProgressBar) is inserted into the document. That is - if the object is not 
> contained within the already referenced libraries/object files. Apparently 
> this automatic referencing browses through available object files and finds 
> some of my third-party software also. A call to these files then seems to 
> invoke the installer. At least that is my current understanding of the 
> problem.
>
> Still - why referencing a certain ActiveX where the object file is known 
> would invoke other ActiveX object code is beyond me...
>
>> Also, the controls must be installed and properly registered on the target 
>> machine the MSO project runs on. That means if your project will be used on 
>> Vista OS or higher you'll have to distribute and register these controls on 
>> that machine. This also means you'll have to develop your project on a 
>> machine that has these OCXs properly installed.
>
> I don't understand what that has to do with the topic...? I am not trying to 
> develop an office project, I am observing a strange/unwanted behaviour of an 
> ActiveX control in office... And trying to find the cause.
>
> Cheers,
>
>    Lars

Well, whether you accept this or not, once you start adding non-office 
controls to an office doc YOU ARE building an office project.

Also, any ActiveX control that is not part of the standard office 
controls should be referenced in the VBE so the MSO host app doesn't 
have to go through all this hooplah you're complaining about. Setting 
the reference to the appropriate lib obviates this 'automatic' action 
you speak of. Being one who uses both these controls in many MSO 
situations, I've never had the behavior you speak of happen to me nor 
to any of my users.

Maybe, as Mayayana suggested, you should ask for help in a VBA group. 
(<BTW> if that happens to be one that I monitor I'll just have the same 
advice and so I won't bother repeating it there)

-- 
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc

[toc] | [prev] | [next] | [standalone]

#1884

GS wrote:
> Well, whether you accept this or not, once you start adding non-office 
> controls to an office doc YOU ARE building an office project.

Whatever you feel comfortable calling it...

> Also, any ActiveX control that is not part of the standard office 
> controls should be referenced in the VBE so the MSO host app doesn't 
> have to go through all this hooplah you're complaining about.

The components in question are part of the "Microsoft Windows Common 
Controls 6.0 (SP6)" - and I just tried it: added the reference to this 
(mscomctl.ocx) to the project first, then inserted the ProgressBar - it 
still starts the "hooplah" :(


> Setting the reference to the appropriate lib obviates this 'automatic' action 
> you speak of.

Sadly that did not work. I wonder if there is an option to turn this 
behaviour off for MS Office... I believe - since the library is not 
normally listed within the available references - windows starts a file 
search and "asks" each file available to it whether it has that control 
the user is trying to insert into his project. And calling that method 
for one of the libraries of my third party software invokes its 
installer (which is poor programming by the third party).

> situations, I've never had the behavior you speak of happen to me nor to 
> any of my users.

Are you sure? Because - without that particular software installed, it 
"seems" normal here also - yet I am pretty sure the unwanted behaviour 
of office is that it searches other libaries for the object in question, 
even though it has a valid reference. And this third party s/w I have 
here merely adds a poor program behaviour that *shows* this unwanted 
behaviour of the reference manager...

> Maybe, as Mayayana suggested, you should ask for help in a VBA group.

I am pretty sure that this problem is caused by the references 
management, which (like the VBA editor) has been shared between VB and 
VBA since office 2k or 2k3 believe(?)...

I could install regular VB and see if the behaviour is reproducible with 
that also. Maybe will do that.

Cheers,

   Lars

[toc] | [prev] | [next] | [standalone]

#1876

GS wrote:
> After serious thinking Lars Uffmann wrote :
>> [Fullquote removed]
> 
> First thing you need to understand is that ANY MS Office project that 
> uses either of these controls needs to have a reference set to them in 
> the VBE (Visual Basic Editor).

I do not have the feeling that you fully understood my post. The MS 
Windows Common Controls are properly registered with the MS Office 2003 
installation. And if they weren't, the project would be complaining 
about the ActiveX control being unknown/not found.

But to be fair, you got me one step further: The component registration 
(reference creation) happens automatically, when the Common Control 
(e.g. ProgressBar) is inserted into the document. That is - if the 
object is not contained within the already referenced libraries/object 
files. Apparently this automatic referencing browses through available 
object files and finds some of my third-party software also. A call to 
these files then seems to invoke the installer. At least that is my 
current understanding of the problem.

Still - why referencing a certain ActiveX where the object file is known 
would invoke other ActiveX object code is beyond me...

> Also, the controls must be installed and properly registered on the 
> target machine the MSO project runs on. That means if your project will 
> be used on Vista OS or higher you'll have to distribute and register 
> these controls on that machine. This also means you'll have to develop 
> your project on a machine that has these OCXs properly installed.

I don't understand what that has to do with the topic...? I am not 
trying to develop an office project, I am observing a strange/unwanted 
behaviour of an ActiveX control in office... And trying to find the cause.

Cheers,

   Lars

[toc] | [prev] | [next] | [standalone]

#1879

After serious thinking Lars Uffmann wrote :
> Hey everyone!
>
> I stumbled upon this behaviour which has me somewhat concerned about possible 
> exploits:
>
> OS: - WinXP Professional SP3 english
>      - security patches up to date as of 2011-02-03
>
> Office Version: 2003
>
> When inserting any ActiveX control contained in either mscomctl.ocx or 
> comctl32.ocx into an office document, the installer of a proprietary 
> software, that I sadly can not share (as much as I would like to have someone 
> reproduce this issue) is invoked.
>
> The installer pops up with a "reconfiguring ..." dialog, not allowing the 
> user any options other than to cancel the process. After that (aborting or 
> letting it finish), the ActiveX control is inserted into the document and 
> behaves as expected.
>
> This usually happens twice, after which the control behaves as expected 
> without invoking that installer. Some times the installer is invoked twice in 
> a row upon one insertion of ActiveX control, sometimes it happens a few more 
> times - but mostly the aforementioned two times.
>
> If the window loses focus (does not work with alt-tabbing, does work with 
> e.g. launching task manager or windows explorer and switching back to the 
> office application), the unwanted behaviour returns.
>
> The comctl32.ocx on a standard windows xp (SP3) will complain that it's not 
> licensed properly and not insert the ActiveX component selected, however, it 
> will still induce the unwanted behaviour of invoking the third party software 
> installer.
>
> I have checked the file version of mscomctl.ocx before vs. after installation 
> of that third party software. The md5sum stays the same. I take that to mean 
> that it is not modified by the installation.
>
> Reproducible with: Microsoft ProgressBar Control 6.0 (SP4), also with 
> ListView, ImageList and TreeView as well as a couple others, tested in MS 
> Word, Access, Excel
>
> NOT reproduciple in MS Powerpoint!
>
> ***Now my question:*** Can anyone list the means by which an ActiveX control 
> can invoke some third party software upon first time being loaded?
>
> Given that it does not know about the third party software (and no 
> dependency), and that this is completely unwanted behaviour, I would like 
> someone with more understanding than I have to tell me whether this means 
> that there is a hook in that common control library that will allow unwanted 
> execution of code, or only installed code, or not at all.
>
> Thank you!
>
>     Lars

First thing you need to understand is that ANY MS Office project that 
uses either of these controls needs to have a reference set to them in 
the VBE (Visual Basic Editor).

Also, the controls must be installed and properly registered on the 
target machine the MSO project runs on. That means if your project will 
be used on Vista OS or higher you'll have to distribute and register 
these controls on that machine. This also means you'll have to develop 
your project on a machine that has these OCXs properly installed.

-- 
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.basic.visual.misc

csiph-web