I have been blocking ActiveX for a long time by using KillBits (Kb240797). I
recently became aware of Manageing Add Ons (Kb883256).

Manageing Add-ons seems more like enableing/disableing them once they are
installed. Where as KillBit seems to stop them from ever getting on a
machine, is this correct?

If this theory is correct I could for example obtain the CLSID for Yahoo
Toolbar. Set the Killbit and it would not be able to get installed on my
machine?

See any benifit in setting the registry keys on both? I

Hi Yogi,

I am no expert but I think the ActiveX Compatibility kill bit just stops the
control from being rendered within an <object> tag so that it can't be
scripted.
Manage Add-ons removes the CLSID of the component from IE's Toolbar, Menu
Extensions or BHO's list.

In both cases the installation of an ActiveX component to your machine is
not blocked. Indeed you will find that many of the CLSIDs in your ActiveX
Compatibility list have no corresponding entry under HKCR\CLSID.

Regards.
"Yogi_Bear_79" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>I have been blocking ActiveX for a long time by using KillBits (Kb240797).
>I
> recently became aware of Manageing Add Ons (Kb883256).
>
> Manageing Add-ons seems more like enableing/disableing them once they are
> installed. Where as KillBit seems to stop them from ever getting on a
> machine, is this correct?
>
> If this theory is correct I could for example obtain the CLSID for Yahoo
> Toolbar. Set the Killbit and it would not be able to get installed on my
> machine?
>
> See any benifit in setting the registry keys on both? I
>
>
>

"Yogi_Bear_79" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>I have been blocking ActiveX for a long time by using KillBits (Kb240797).
>I
> recently became aware of Manageing Add Ons (Kb883256).
>
> Manageing Add-ons seems more like enableing/disableing them once they are
> installed. Where as KillBit seems to stop them from ever getting on a
> machine, is this correct?
>
> If this theory is correct I could for example obtain the CLSID for Yahoo
> Toolbar. Set the Killbit and it would not be able to get installed on my
> machine?
>
> See any benifit in setting the registry keys on both? I


Killbits in a registry entry for the class ID of an ActiveX object *NEVER*
prevents that AX control from getting onto your host. It only prevents it
from being referenced (i.e., called) through the registry. So the malware
can still get onto your host but hopefully it cannot run.

At one time, the author of SpywareBlaster was clear in how his product
worked in setting killbits which would prevent executing the AX control but
did not prevent it from getting put onto the computer. Later he started
making non-truths (he got caught up in the anti-malware prattle) saying that
his product would prevent *installation* of the bad AX controls included in
his killbit list. He backed off from that claim when it was shown that
setting killbits never prevents an install program from depositing the files
on the computer.

So like with eunuchs, rather than keep the men from messing with the harem,
just snip off their important bits to make them impotent. They're still
there but can't molest. The killbit doesn't stop the installation program
from depositing the files onto your computer. The killbits won't remove
those files. The killbits only prevent the AX control from being called
through its reference in the registry. DLLs may also get registered so
their path and attributes are defined there and any application can make a
call to an entry point (function) without having to know where is the DLL;
however, a program can still make a direct call to a function within a DLL
file. I don't do AX programming and don't know if direct calls to the AX
file can be used instead of requiring the use of the registry.

Since the installation of the malware could also update the registry, it
would seem that setting the killbit for it beforehand would be fruitless
since the install program could change that registry key to unkill the AX
control. So it seems the killbit scheme is an afterthough approach where
you periodically need to update those registry keys to [re]set the killbits.
That's why I'm not sure how effective are killbits. Malware gets installed,
updates the registry, removes the killbit value, if set, and the malware
will run okay until the next time you rerun SpywareBlaster or whatever you
use to add the killbit values. Since you can edit the registry to add the
killbit or use software to do so, why can't an install program running under
the same account also perform the same action (but to unkill) as did you or
the software that you used? If you let the AX control install through the
Windows-supplied installation routines then the killbit is honored. If,
however, you open an attachment and run it, the installation program does
whatever it wants, and malware doesn't care about killbits and might be
smart enough to unkill them for itself.

You might want to wander over to a hacker group to ask how to circumvent the
kill bit registry entries.

--
__________________________________________________
Post replies to the newsgroup. Share with others.
For e-mail: Remove "NIX" and add "#VN" to Subject.
__________________________________________________

"Vanguard" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> "Yogi_Bear_79" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>>I have been blocking ActiveX for a long time by using KillBits (Kb240797).
>>I
>> recently became aware of Manageing Add Ons (Kb883256).
>>
>> Manageing Add-ons seems more like enableing/disableing them once they are
>> installed. Where as KillBit seems to stop them from ever getting on a
>> machine, is this correct?
>>
>> If this theory is correct I could for example obtain the CLSID for Yahoo
>> Toolbar. Set the Killbit and it would not be able to get installed on my
>> machine?
>>
>> See any benifit in setting the registry keys on both? I
>
>
> Killbits in a registry entry for the class ID of an ActiveX object *NEVER*
> prevents that AX control from getting onto your host. It only prevents it
> from being referenced (i.e., called) through the registry. So the malware
> can still get onto your host but hopefully it cannot run.
>
> At one time, the author of SpywareBlaster was clear in how his product
> worked in setting killbits which would prevent executing the AX control
> but did not prevent it from getting put onto the computer. Later he
> started making non-truths (he got caught up in the anti-malware prattle)
> saying that his product would prevent *installation* of the bad AX
> controls included in his killbit list. He backed off from that claim when
> it was shown that setting killbits never prevents an install program from
> depositing the files on the computer.
>
> So like with eunuchs, rather than keep the men from messing with the
> harem, just snip off their important bits to make them impotent. They're
> still there but can't molest. The killbit doesn't stop the installation
> program from depositing the files onto your computer. The killbits won't
> remove those files. The killbits only prevent the AX control from being
> called through its reference in the registry. DLLs may also get
> registered so their path and attributes are defined there and any
> application can make a call to an entry point (function) without having to
> know where is the DLL; however, a program can still make a direct call to
> a function within a DLL file. I don't do AX programming and don't know if
> direct calls to the AX file can be used instead of requiring the use of
> the registry.
>
> Since the installation of the malware could also update the registry, it
> would seem that setting the killbit for it beforehand would be fruitless
> since the install program could change that registry key to unkill the AX
> control. So it seems the killbit scheme is an afterthough approach where
> you periodically need to update those registry keys to [re]set the
> killbits. That's why I'm not sure how effective are killbits. Malware
> gets installed, updates the registry, removes the killbit value, if set,
> and the malware will run okay until the next time you rerun SpywareBlaster
> or whatever you use to add the killbit values. Since you can edit the
> registry to add the killbit or use software to do so, why can't an install
> program running under the same account also perform the same action (but
> to unkill) as did you or the software that you used? If you let the AX
> control install through the Windows-supplied installation routines then
> the killbit is honored. If, however, you open an attachment and run it,
> the installation program does whatever it wants, and malware doesn't care
> about killbits and might be smart enough to unkill them for itself.
>
> You might want to wander over to a hacker group to ask how to circumvent
> the kill bit registry entries.
>
> --
> __________________________________________________
> Post replies to the newsgroup. Share with others.
> For e-mail: Remove "NIX" and add "#VN" to Subject.
> __________________________________________________
>
Extremely imformative. Since I admin a lot of machines I created my own
program that Sets the KillBit on 1492 ActiveX components, all of which the
offending CLSID is entered into the registry, then the KillBit is applied. I
also Add 26,000 sites to the Restricted Sites zone, I then customize all
settings for the zone. I set all to disabled. I also add the same 26,000
sites to my blocked cookies list. I set the cookies to prompt for 1st Party
and Block for 3rd.

Finally since I am bad about updateing my program, I use Spybots Immunize
feature to add to the above items.

I am repsonsible for 120 systems all on .com connectons with simple SOHO
routers. I also maintian 30 ssytems for a small company, plus the usual
freinds and family. I can say that in two years with these methods that none
of my machines "witht proper cookie management" by the users have had any
spyware found on them. I use Adaware, SpyBot and Hijackthis to periodically
check them.

The ones with spyware are usually foudn to have had the cookies settings
back to default or a user that simply accepts all cookies manaully.

So with that said. I am wondering how many of my settings are actually doing
something productive, and if maybe some can be discarded.

"Yogi_Bear_79" <(E-Mail Removed)> wrote in message
news:s4-dnX7yZ64mWbzZRVn-(E-Mail Removed)...
>
> "Vanguard" <(E-Mail Removed)> wrote in message
> news:%(E-Mail Removed)...
>> "Yogi_Bear_79" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>>I have been blocking ActiveX for a long time by using KillBits
>>>(Kb240797). I
>>> recently became aware of Manageing Add Ons (Kb883256).
>>>
>>> Manageing Add-ons seems more like enableing/disableing them once they
>>> are
>>> installed. Where as KillBit seems to stop them from ever getting on a
>>> machine, is this correct?
>>>
>>> If this theory is correct I could for example obtain the CLSID for Yahoo
>>> Toolbar. Set the Killbit and it would not be able to get installed on my
>>> machine?
>>>
>>> See any benifit in setting the registry keys on both? I
>>
>>
>> Killbits in a registry entry for the class ID of an ActiveX object
>> *NEVER* prevents that AX control from getting onto your host. It only
>> prevents it from being referenced (i.e., called) through the registry.
>> So the malware can still get onto your host but hopefully it cannot run.
>>
>> At one time, the author of SpywareBlaster was clear in how his product
>> worked in setting killbits which would prevent executing the AX control
>> but did not prevent it from getting put onto the computer. Later he
>> started making non-truths (he got caught up in the anti-malware prattle)
>> saying that his product would prevent *installation* of the bad AX
>> controls included in his killbit list. He backed off from that claim
>> when it was shown that setting killbits never prevents an install program
>> from depositing the files on the computer.
>>
>> So like with eunuchs, rather than keep the men from messing with the
>> harem, just snip off their important bits to make them impotent. They're
>> still there but can't molest. The killbit doesn't stop the installation
>> program from depositing the files onto your computer. The killbits won't
>> remove those files. The killbits only prevent the AX control from being
>> called through its reference in the registry. DLLs may also get
>> registered so their path and attributes are defined there and any
>> application can make a call to an entry point (function) without having
>> to know where is the DLL; however, a program can still make a direct call
>> to a function within a DLL file. I don't do AX programming and don't
>> know if direct calls to the AX file can be used instead of requiring the
>> use of the registry.
>>
>> Since the installation of the malware could also update the registry, it
>> would seem that setting the killbit for it beforehand would be fruitless
>> since the install program could change that registry key to unkill the AX
>> control. So it seems the killbit scheme is an afterthough approach where
>> you periodically need to update those registry keys to [re]set the
>> killbits. That's why I'm not sure how effective are killbits. Malware
>> gets installed, updates the registry, removes the killbit value, if set,
>> and the malware will run okay until the next time you rerun
>> SpywareBlaster or whatever you use to add the killbit values. Since you
>> can edit the registry to add the killbit or use software to do so, why
>> can't an install program running under the same account also perform the
>> same action (but to unkill) as did you or the software that you used? If
>> you let the AX control install through the Windows-supplied installation
>> routines then the killbit is honored. If, however, you open an
>> attachment and run it, the installation program does whatever it wants,
>> and malware doesn't care about killbits and might be smart enough to
>> unkill them for itself.
>>
>> You might want to wander over to a hacker group to ask how to circumvent
>> the kill bit registry entries.
>>
>> --
>> __________________________________________________
>> Post replies to the newsgroup. Share with others.
>> For e-mail: Remove "NIX" and add "#VN" to Subject.
>> __________________________________________________
>>
> Extremely imformative. Since I admin a lot of machines I created my own
> program that Sets the KillBit on 1492 ActiveX components, all of which the
> offending CLSID is entered into the registry, then the KillBit is applied.

If the user is attempting to install the AX control when a prompt appears in
IE then the kill bit is [probably] honored since a "closed" install program
is being used rather than some unknown install program. Just be sure to
watch those e-mail attachments or downloads since that is also how AX
controls can be installed. For example, the download for Adobe Reader runs
as an install program (but NOT inside of IE) and it installs an AX control
(used to display the PDF file within the browser window).

> also Add 26,000 sites to the Restricted Sites zone, I then customize all
> settings for the zone. I set all to disabled.

That only neuters those sites. It does not prevent users from visiting
them. Fortunately one of the settings is for file downloads (which should
be disabled) so they can't get the malware that way.

> I also add the same 26,000 sites to my blocked cookies list. I set the
> cookies to prompt for 1st Party and Block for 3rd.

I also set cookies to allow 1st party, block 3rd party, and allow
per-session cookies (they expire when the last instance of IE is unloaded).
However, I find a huge list of "bad domains" for cookies to be a complete
waste of time but understand that I am in a different position than you.
I'm speaking of a user managing their own host rather than an admin managing
several hundred hosts. I use cookie domain whitelisting. Only those
domains in the whitelist will have their cookies retained after IE is
exited. All other cookies (for non-whitelisted domains) will get deleted;
i.e., they are forced to be per-session cookies. This lets me allow the
cookies because often they are needed for proper painting of the web pages
on a site or for navigation throughout that site, but they get deleted when
I leave the site and exit IE. Whitelisting means I have less than 2 dozen
trusted domains for whom I allow their cookies to remain on my host. All
others get forcibly purged. However, in your situation, I can see the need
to using a "bad domain" cookie blacklist but unfortunately that usually
means that you are letting someone else decide for you what is a bad and
good domain regarding cookies. Unless YOU are the one creating and updating
the cookie domain list, you aren't managing it at all.

I'll use the "bad sites" list to add to the Restricted Sites security zone
because it neuters a site rather than prohibits visiting that site. If I
disagree with the classification, I can remove that site from the bad list
or add it to a different security zone. In direct opposition, however, I
use whitelisting to manage just a few good cookie domains rather than
allocate the responsibility to some unknown altruistic author(s) that
maintain a bad cookie domain list.

> Finally since I am bad about updateing my program, I use Spybots Immunize
> feature to add to the above items.

I prefer to use the SpywareBlaster kill bit update. They update the
registry key correctly whereas I see several entries by Spybot's immunize
will neglect the hierarchy for the domains when adding the registry keys for
the "bad domains" in the Restricted Sites security zone. They may still
work but won't get removed if the list is updated to no longer list that
domain. In the past, typically the SpywareBlaster kill bit list included
everything listed in Spybot's kill bit list, and more, and, in fact, Spybot
used to recommend using SpywareBlaster if it detected its presence.

--
__________________________________________________
Post replies to the newsgroup. Share with others.
For e-mail: Remove "NIX" and add "#VN" to Subject.
__________________________________________________

Vanguard <(E-Mail Removed)> wrote:

> I use cookie domain whitelisting. Only those
> domains in the whitelist will have their cookies retained after IE is
> exited. All other cookies (for non-whitelisted domains) will get deleted;
> i.e., they are forced to be per-session cookies. This lets me allow the
> cookies because often they are needed for proper painting of the web pages
> on a site or for navigation throughout that site, but they get deleted when
> I leave the site and exit IE.

How do you do whitelisting?

--
Gary L. Smith
Columbus, Ohio

"Gary Smith" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Vanguard <(E-Mail Removed)> wrote:
>
>> I use cookie domain whitelisting. Only those
>> domains in the whitelist will have their cookies retained after IE is
>> exited. All other cookies (for non-whitelisted domains) will get
>> deleted;
>> i.e., they are forced to be per-session cookies. This lets me allow the
>> cookies because often they are needed for proper painting of the web
>> pages
>> on a site or for navigation throughout that site, but they get deleted
>> when
>> I leave the site and exit IE.
>
> How do you do whitelisting?
>
> --
> Gary L. Smith
> Columbus, Ohio


As an end user, I would use a cookie manager. However, the popup blocker
program that I use (PopUpCop) also includes the cookie whitelisting function
so I don't need to bother with running a cookie manager. PopUpCop only
loads when IE is loaded. That is the only time you have to manage cookies,
anyway. Cookie managers load as a background process that continually
consumes memory and some CPU cycles even when you are not in a browser.

Whitelisting merely means that you will keep those cookies left when
visiting domains that are in that list. However, you still need an option
that says all non-whitelisted domains will get their cookies deleted. In
PopUpCop, whitelisting a domain in the cookie list means it gets kept; if
the domain is not in the whitelist, the cookie for that domain gets deleted
upon exit from the last instance of IE. Cookie managers work similarly but
may provide both a whitelist and blacklist. I wouldn't bother maintaining a
blacklist. I only keep cookies from a few domains so whitelisting them and
deleting all others makes my implied blacklist very huge (i.e., all domains
for cookies are blacklisted unless whitelisted).

This is really an end-user solution because they are using a cookie manager
on their own host. It lets them manage just a dozen domains to keep their
cookies rather than download a blacklist from someone else to whom you are
relegating the authority in deciding which are the good and bad domains.
Besides, just because a domain is good (because of its absence in the
blacklist) doesn't mean I want to keep their cookie. I occasionally log
onto Yahoo Mail using the browser interface and they use a cookie and it is
a good domain but I don't bother whitelisting them because I don't want
their cookie around after the mail session. So I whitelist a few good
domains, the other good domains will get the cookies removed, and the bad
domains gets their cookies removed. This lets the site function normally
that uses cookies, sometimes for security purposes, but gets rid of them
when they are no longer needed (because if I exit the browser then I don't
need their cookie for proper painting of their pages or to authorize
navigation around their site).

IE has its Allow list for cookie domains. It also has its Block list. The
problem with IE's Allow list is that it allows the cookie to remain but does
NOT auto-delete all the other cookies upon exit from IE. A Block list will
not list every bad domain nor will it list the good domains that I still
don't want their cookies. So if IE had the option "purge non-whitelisted
cookies on exit" then its whitelist or Allow list would be of practical use
(and I would never be bothered with having to continually maintain an
ever-increasing and sometimes outdated blacklist of domains).

With PopUpCop, I can add a list of good to-keep domains (versus good
not-to-keep domains) in its own whitelist. It also has an option to
auto-retain cookies from sites listed in the Trusted Sites security zone.
All other cookies are purged (so they are effectively handled as per-session
cookies). If I didn't have PopUpCop, or if I used a different browser, I
would look into using a cookie manager even if I had to pay for one.
However, I'm speaking as an end-user that manages his own cookie whitelist
versus a network admin trying to force a whitelist upon the users (and,
again, the whitelist is reduced in effectiveness without the option to purge
all non-whitelisted cookies). Firefox also has its cookie settings and
cookie manager with its Allow (white) and Block (black) lists but it still
lacks an option to purge all *non-whitelisted* cookies on *exit* (which
would totally obviate the need for a blacklist but allows ALL cookies during
the browser session so sites work okay). I only want to *keep* the
whitelisted cookies AFTER exiting the browser. I don't want to block any
[1st party] cookies during the browser session. The privacy threat of
cookies is not during the browser session but between browser sessions.
Marketing doesn't care about your first visit but about your revisits
(tracking a one-time visit is worthless).

--
__________________________________________________
Post replies to the newsgroup. Share with others.
For e-mail: Remove "NIX" and add "#VN" to Subject.
__________________________________________________

Vanguard <(E-Mail Removed)> wrote:

[An extensive descrition of cookie whitelisting]

Thanks for that. It was quite helpful.

--
Gary L. Smith
Columbus, Ohio