Problem with latest security update kb891781 (dhtmled.ocx update)

[Guest]

Hi,
today I've installed latest security update kb891781, which caused, that our
application for web content management that uses MSHTML editing ActiveX
control dhtmled.ocx, stops work. Our application is developed in Delphi and
uses this component for content managing.
I found the problem (after tracing some debug info)- the application
couldn't get access to the DOM (IHtmlEditDocument2 interface) through
IHTMLEdit interface, so it raised the exception "Unknown interface".
I didn't find any workaround than uninstall this security fix. Then
everything was OK as before. Of course, I spent some time with security
settings in IE - I enabled almost everything, but nothing helped.

I tried to find whether some other has the same problem and I found some
polish application based on this component having the same trouble.

Does anybody has any idea where the problem is?
Thanx.

 

[Jon Kennedy]

http://www.microsoft.com/technet/security/bulletin/ms05-013.mspx
From the "General Information" section:

What is the Local Machine zone lockdown?
In Windows XP Service Pack 2, all local files and content that are processed
by Internet Explorer has additional security applied to it in the Local
Machine zone. This feature restricts HTML in the Local Machine zone. This
feature also restricts HTML that is hosted in Internet Explorer. These
restrictions help mitigate attacks where the Local Machine zone is used as
an attack vector to load malicious HTML code.

Because of this change, ActiveX script in local HTML pages that are viewed
inside Internet Explorer will not run. Also, script in local HTML pages that
are viewed inside Internet Explorer prompts the user for permission to run.

For how to change the local machine zone security settings, see this
article:

How to strengthen the security settings for the Local Machine zone in
Internet Explorer
http://support.microsoft.com/default.aspx?scid=kb;en-us;833633

 

[Guest]

Thanks for help, but still I didn't succeeded. For further explanation: our
application is stand-alone application using dhtmled.ocx and mshtml for html
manipulation. That MS bulletin says, that SP2 increases security
(=restrictions) for Local zones. That's ok. Our application worked well with
this sp2. Even though with all updates released up to now but the mentioned
KB891781, that replaces the ActiveX component. That's strange. This update
should fix possible remote attack, but it seems, that those guys did some
thing wrong. The ActiveX component (dhtmled.ocx) runs, the application
normally initializes itself (including ActiveX component dhtmled), but you
can't access its DOM interface for document manipulation. When you do such
thing "Interface unknown" exception raises. This changes after apply of
kb891781.

According the article -
http://support.microsoft.com/default.aspx?scid=kb;en-us;833633
I played with registry and perrmit almost everything for local zone
(computer), intranet, internet and so on. Nothing has changed. That's really
annoying :-(.
We have to recommend our customers using the application not to install this
update untill the cleaner solution will arisen. I hope, that scenario of MS
being unable to fix this problem with vulnerability correctly so they turns
some features off, is not true...

Regards Jiri Fartak ([email protected])

 

[Pat Magnan]

The problem is affecting Windows 2000 and Windows 98 customers of ours
as well. So I don't think it relates to SP2 issues (I wish it were
that easy). We've debugged into it also, and found the same problem.
No access is being allowed to the DOM object anymore. The interfaces
are actually present, but return NULL pointers, so the 'no such
interface' isn't quite accurate, but may as well be an accurate return
code. The interface exists, it's just useless.

Someone made an error implementing the hotfix as near as I can tell,
either that, or the interfaces have been altered and the way you now
use this COM object is not yet documented? Mind you, I thought when
changing a COM object, the old interfaces were not to be removed such
as not to break existing applications.

Hopefully, it's just a matter of changing the way such applications
access the object, but for the moment, we've had to publish removal
instructions to keep in business.

It is interesting to note that our application is also accessing the
object from Delphi.

 

[salimnair]

This is definitely not an isoloated issue, and I strongly doubt has
anything to do with implementing language as well. We have an
application in delphi uses this OCX having similar issues (interface
not supported). Interestingly enough, I can reproduce the same
behaviour with C#. It appears that trying to change DOM properties is
what causing this error, but I am not sure. Yes, there is something
fishy going on with this hotfix!!!!!

 

[Pat Magnan]

We have confirmed the problem in our company's application. It does
not appear resolvable by changing any setting on affected computers to
date. We created a simple test application (also in Delphi), and any
COM interface which used to be exposed to access the DOM object now
returns a NULL pointer, rather than allowing access to the object.

We tried importing the triedit.dll directly as a typelib, but still
have no method of getting access to the IHTMLDocument2 interface.

The only solution we can recommend to customers is to not deploy it,
which is a solution we really shouldn't have to recommend. Something
slipped through QA here, because you're not alone, a number of
applications are broken at this time.

I'm hoping either there's a fix to the fix, or we receive
documentation sometime soon on how we now use this control in
applications, 'safely' as it were.

 

[salimnair]

List of applications that are known to show this problem

1. Macromedia Homesite
2. KLZ NewsRoom4.

(Please add to the list if you find any other apps)

salim

 

[Guest]

I think this is interfering w/ Norton AV 2003 & 2005 as well. When you try to
launch NAV you get the message: " Your internet security settings prohibit
ActiveX controls on this page. As a result, the page may not display
properly." and the NAV UI doesn't load completely and fails to react to any
mouse clicks.

When you try to change the internet security settings in the Internet zone,
it reports: "The recommended security level for this zone is "Medium". The
level that you have chosen is lower than this. Please choose a security level
of "Medium" or higher."

When you try to change the internet security settings in the Restricted
Sites zone, it reports: "The recommended security level for this zone is
"High". The level that you have chosen is lower than this. Please choose a
security level of "High" or higher."

Am I talking about the same problem here? Sounds similar to me.

 

[Guest]

I think Norton AV 2003 & 2005 are rendered useless because of this problem.
Apparently they use ActiveX to work their front end UI. When you launch NAV
you get the message: "Your internet security settings prohibit ActiveX
controls on this page. As a result, the page may not display properly."

When you try to change the internet security settings in the Internet zone,
it reports: "The recommended security level for this zone is "Medium". The
level that you have chosen is lower than this. Please choose a security level
of "Medium" or higher."

When you try to change the internet security settings in the Restricted
Sites zone, it reports: "The recommended security level for this zone is
"High". The level that you have chosen is lower than this. Please choose a
security level of "High" or higher."

Am I talking about the same problem here?

 

[Guest]

Trellian WebPage (web editor) has the same problem: inoperability after
applying KB891781 w/"no such interface" error message.. Only work-around
offered at present is to un-install the patch, which of course is
unacceptable.
Bob123

 

[Pat Magnan]

This is definitely not an isoloated issue, and I strongly doubt has
anything to do with implementing language as well. We have an
application in delphi uses this OCX having similar issues (interface
not supported). Interestingly enough, I can reproduce the same
behaviour with C#. It appears that trying to change DOM properties is
what causing this error, but I am not sure. Yes, there is something
fishy going on with this hotfix!!!!!

Here's something interesting:

Install the hotfix on your system if you have not already, and if you
have access to VB 6 (2003 is the same result), try this application:
- one DHTML Edit control:
- two buttons

The following click events for each button:
--
Private Sub Command1_Click()
DHTMLEdit1.DOM.body.innerHTML = "HELLO VB"
End Sub

Private Sub Command2_Click()
MsgBox DHTMLEdit1.DOM.body.innerHTML
End Sub
---

Then try this delphi program (same form layout as VB program above),
again just the click events:

----
implementation

{$R *.DFM}

procedure TForm1.Button1Click(Sender: TObject);
begin
DHTMLEdit1.DOM.body.innerHTML:= 'Hello Delphi';
end;

procedure TForm1.Button2Click(Sender: TObject);
begin
ShowMessage( DHTMLEdit1.DOM.body.innerHTML );
end;

end.
----

I'm neither a Delphi nor a VB programmer (C++ is my trade), but it
doesn't take intimate knowledge of either environment to see they are
the same program, one works after the patch, the other does not. I
would guess it's something to do with the way Delphi marshals the
calls, but I cannot say what. I even spent an hour 'backing out'
Delphi's compiled version of the controls, then re-importing the
typelibraries, forcing Dephi to regenerate the wrapper code, which
yields the same 'interface not supported' message.

I haven't tested this from Microsoft's C++ environment, I'm positive
it will work just like the VB example, C# I have not tested either, if
C# is broken as well, then Microsoft may do something about it (or
this just proves they don't use it in their products yet), otherwise,
I think we need to be looking for a tools vendor solution sadly

 

[Toril]

We have a development tool called QBE Vision. A QBE application that
was using the DHTML control got the same problem after the security
patch as you did. I assembly debugged a VB application that was using
the DHTM control and compared it with a QBE application using the same
control. And I found a difference. At some point the control makes a
call to IOleClientSite->GetContainer. VB returned an interface, while
QBE returned E_NOTIMPL. After implementing
IOleClientSite->GetContainer the QBE application started to work. May
be it is the same problem with Dephi. You only need to implement the
IUnknown part of IOleContainer. The rest of the methods can return
E_NOTIMPL.

Toril

 

[Marco Zuiderwijk]

Hey, that's interesting! We are using C++ Builder and having the same
problems. Can you explain in a little more detail how you added the
IOleClientSite interface. Is it an interface on the window which contains
the DHTML control, or an interface on the wrapper for the DHTML control?

Regards,
Marco

 

[Toril]

IOleClientSite is an interface supported by the container of an
embedded object (an ActiveX control is an embedded object). When a
control is created IOleClientSite is given to the object either
through IQuickActivate->QuickActivate or by through
IOleObject->SetClientSite. I have never used C++ Builder so I don't
know if this is under your control or handled by C++ Builder. I would
think that it is handled by C++ Builder.

Toril

 

[Toril]

Here is my C++ code. It includes a simple implementation of
IOleContainer and the code for IOleClientSite->GetContainer:

class FAR CImpIOleContainer : public IOleContainer
{
protected:
ULONG m_cRef;

public:
CImpIOleContainer(void);
~CImpIOleContainer(void);

STDMETHODIMP QueryInterface(REFIID, LPLPVOID);
STDMETHODIMP_(ULONG) AddRef(void);
STDMETHODIMP_(ULONG) Release(void);

STDMETHODIMP ParseDisplayName(IBindCtx * pbc, LPOLESTR
pszDisplayName, ULONG * pchEaten, IMoniker ** ppmkOut);
STDMETHODIMP EnumObjects(DWORD grfFlags, IEnumUnknown **ppenum);
STDMETHODIMP LockContainer(BOOL fLock);
};


CImpIOleContainer::CImpIOleContainer(void)
{
m_cRef=0;
return;
}

CImpIOleContainer::~CImpIOleContainer(void)
{
return;
}

STDMETHODIMP CImpIOleContainer::QueryInterface(REFIID riid, LPLPVOID
ppv) {
*ppv=NULL;

if (IID_IUnknown==riid || IID_IOleContainer==riid)
*ppv=this;

if (NULL!=*ppv) {
((LPUNKNOWN)*ppv)->AddRef();
return NOERROR;
}

return ResultFromScode(E_NOINTERFACE);
}

STDMETHODIMP_(ULONG) CImpIOleContainer::AddRef(void)
{
return ++m_cRef;
}

STDMETHODIMP_(ULONG) CImpIOleContainer::Release(void)
{
if (0!=--m_cRef)
return m_cRef;

delete this;
return 0;
}

STDMETHODIMP CImpIOleContainer:arseDisplayName(IBindCtx * pbc,
LPOLESTR pszDisplayName, ULONG * pchEaten, IMoniker ** ppmkOut) {
return ResultFromScode(E_NOTIMPL);
}

STDMETHODIMP CImpIOleContainer::EnumObjects(DWORD grfFlags,
IEnumUnknown **ppenum) {
return ResultFromScode(E_NOTIMPL);
}

STDMETHODIMP CImpIOleContainer::LockContainer(BOOL fLock)
{
return ResultFromScode(E_NOTIMPL);
}

And here is the code for OleGetContainer:


STDMETHODIMP CImpIOleClientSite::GetContainer(LPOLECONTAINER FAR
*ppContainer) {
//Only necessary if you allow linking to embeddings
//Security patch caused DHTML editor control to fail if not
implemented
CImpIOleContainer *pIContainer;

pIContainer = new CImpIOleContainer();
if (pIContainer)
return pIContainer->QueryInterface(IID_IOleContainer,
(LPLPVOID)ppContainer);
*ppContainer=NULL;
return ResultFromScode(E_NOTIMPL);
}


Toril