Onderwerp: [Symantec Security Advisor] Symantec Security Check ActiveX Buffer Overflow

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Title: Symantec Security Check ActiveX Buffer Overflow

Date: Monday, June 23, 2003 09:15:19 PM
Threat: Moderate
Impact: System Access
Product: Symantec Security Check

Situation Overview:
Symantec Security Check is a free web-based tool that enables users
to test their computer's exposure to a wide range of on-line threats.
As part of running the check, users may install an ActiveX Control
which remains on the user's system even after the check has
completed.

The current ActiveX Control - which can be named Symantec RuFSI
Utility Class or Symantec RuFSI Registry Information Class - contains
a buffer overflow exploit. The buffer overflow can be exploited when
the user with this ActiveX Control visits a malicious website intent
on exploiting this vulnerability. The exploit can cause Internet
Explorer to crash and/or the execution of arbitrary code on the
user's computer.

Symantec has replaced the current ActiveX Control on the Symantec
Security Check website so that new visitors will not be affected by
the exploit.

Recent visitors to Symantec Security Check should revisit the site
and run a new Security Scan. By running a new scan, the previous
ActiveX Control will be replaced by an updated ActiveX Control that
fixes the buffer overflow condition.

Advanced users can attempt to delete the ActiveX Control by rebooting
and then going into the system folder: %SystemRoot%\Downloaded
Program Files\ and delete "rufsi.dll". This must be done by using the
command prompt and the user must not be on the Symantec Security
Check site at the time.

Statement:
Symantec was made aware of Symantec Security Check's ActiveX buffer
overflow vulnerability today through a public posting on the
Internet. Since hearing of the exploit Symantec has worked diligently
to replace the ActiveX Control on Symantec Security Check. Through
Symantec's customer support, we are working with users who may have
downloaded the exploited ActiveX Control to remove it from their
systems. Although Symantec Security Check is available to both PC and
Mac users, this issue only affects PCs.

Symantec Vulnerability Response Process:
Symantec is a strong supporter of responsible disclosure. It is our
goal to establish a working relationship with researchers who
discover vulnerabilities in Symantec products and to develop, test
and make available updates prior to there being publicly disclosed.
It is ours as well as much of the security communities belief that
premature disclosure can pose a serious threat to the internet. Such
disclosure should be discouraged.

Symantec Security

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0

iQA/AwUBPviB3hMwEkwA14VxEQJ7WgCdHlF3E6/id/tJc0EJBejLq75E2QMAoJIY
Xl3JfZOIT/LXoB8GnqznO3iS
=j4U8
-----END PGP SIGNATURE-----

Aloha, Symantec Security.

Two questions:

1) Does this ActiveX control bear a digital signature? If so, the problem it
causes does not go away simply because there is a new version available from
Symantec. An attacker in possession of the bad code with its attached digital
signature can fool a victim whose computer does not currently have the
vulnerable code installed into trusting the ActiveX control due to the fact
that Symantec's digital signature will validate against the trusted root CA
certificate present by default in Windows -- the existence of the digital
signature on the bad code effectively transfers ownership of millions of other
people's computers to anyone who should become interested in attacking those
computers; it is extremely important that Symantec take further action above
and beyond compiling a new version of the affected code because of the ongoing
threat posed for the duration of the validity of the digital signature.

2) Symantec must have known in advance of this discovery and disclosure that
ActiveX was inherently insecure and that the whole system of digital
signatures and third-party PKI advanced by Microsoft was flawed beyond repair,
yet Symantec chose to put the computing public at risk anyway -- how can
Symantec claim that disclosure is a serious threat that should be discouraged
while Symantec knowingly engages in business behavior that the security
community knows to be unsafe? If Symantec's products were designed with
security as the highest priority, they would be open source and they would
avoid using any technique such as ActiveX controls and digitally signed code
that has been proven to be impossible to manage securely.

> premature disclosure can pose a serious threat to the internet.
> Such disclosure should be discouraged.

It is pointless to fret over the potential threat that disclosure might cause
while we simultaneously ignore the provable threats that our misbehaviors do
cause. Full disclosure is the only protection we have against ourselves and
our own stupidity, and such disclosure should be encouraged.

Sincerely,

Jason Coombs
jasonc@science.org

-----Original Message-----
From: Craig Ozancin [mailto:cozancin@symantec.com]On Behalf Of Sym
Security
Sent: Tuesday, June 24, 2003 7:09 AM
To: bugtraq@securityfocus.com
Subject: [Symantec Security Advisor] Symantec Security Check ActiveX
Buffer Overflow

Title: Symantec Security Check ActiveX Buffer Overflow

Date: Monday, June 23, 2003 09:15:19 PM
Threat: Moderate
Impact: System Access
Product: Symantec Security Check

Situation Overview:
Symantec Security Check is ... an ActiveX Control ...
exploited when the user with this ActiveX Control visits ...

Symantec has replaced the current ActiveX Control on the Symantec
Security Check website so that new visitors will not be affected by
the exploit.

we are working with users who may have downloaded the exploited ActiveX
Control to remove it from their
systems. Although Symantec Security Check is available to both PC and
Mac users, this issue only affects PCs.

Symantec Vulnerability Response Process:
Symantec is a strong supporter of responsible disclosure. It is our
goal to establish a working relationship with researchers who
discover vulnerabilities in Symantec products and to develop, test
and make available updates prior to there being publicly disclosed.
It is ours as well as much of the security communities belief that
premature disclosure can pose a serious threat to the internet. Such
disclosure should be discouraged.

Symantec Security

To further restrict the potential impact of coding flaws in ActiveX
controls, consider sitelocking. =20
Sitelocking can help prevent your control from being illegitimately used
elsewhere.

http://msdn.microsoft.com/downloads/....asp?url=3D/d=
o
wnloads/samples/internet/components/SiteLock/default.asp

-Eric
This posting is provided "AS IS" with no warranties, and confers no
rights.

-----Original Message-----
From: Chris Wysopal [mailto:weld@vulnwatch.org]=20
Sent: Tuesday, June 24, 2003 1:51 PM
To: Jason Coombs
Subject: RE: [Symantec Security Advisor] Symantec Security Check ActiveX
Buffer Overflow



On Tue, 24 Jun 2003, Jason Coombs wrote:

> 1) Does this ActiveX control bear a digital signature? If so, the=20
> problem it causes does not go away simply because there is a new=20
> version available from Symantec. An attacker in possession of the bad=20
> code with its attached digital signature can fool a victim whose=20
> computer does not currently have the vulnerable code installed into=20
> trusting the ActiveX control due to the fact that Symantec's digital=20
> signature will validate against the trusted root CA certificate=20
> present by default in Windows -- the existence of the digital=20
> signature on the bad code effectively transfers ownership of millions=20
> of other people's computers to anyone who should become interested in=20
> attacking those computers; it is extremely important that Symantec=20
> take further action above and beyond compiling a new version of the
affected code because of the ongoing threat posed for the duration of
the validity of the digital signature.

You are absolutely right about attackers using the old control to carry
out an attack.

The new control should have a new CLSID and the kill bit should be set
for the old control's CLSID. Information from the Microsoft knowledge
base on how to set the kill bit is here:

http://support.microsoft.com/default...ort.microsoft=
..
com:80/support/kb/articles/q240/7/97.asp&NoWebContent=3D1

Unfortunately the only way to get this kill bit to be set on the
majority of machines is to get Microsoft to do it through a Windows
update. Until that happens the old signed control can be used by
attackers.

This is the real flaw in the system. The kill bit is only useful to
Microsoft as Symantec has no way of getting all Windows users to set
this bit on the bad CLSID before they are attacked. Perhaps Microsoft
should allow other vendors to send them CLSIDs to kill. Or maybe they
already do allow this but it is not publicized.

-Chris


> Sincerely,
>
> Jason Coombs
> jasonc@science.org

> The new control should have a new CLSID and the kill bit should be set
> for the old control's CLSID. Information from the Microsoft knowledge
> base on how to set the kill bit is here:

So has anyone figured out what the CLSID is of the old control?

(I don't have it on my system so I can't find out, but I would like to
roll out a package to my company to set the kill bit in everyone's
registry, just in case.)

Thanks!
Sandra