On Sun, 16 Oct 2005 16:16:13 -0400, "Colin Nash [MVP]" <cnash x@x
>"cquirke (MVP Windows shell/user)" <cquirkenews@nospam.mvps.org>
>> On Sat, 15 Oct 2005 02:40:40 -0400, "Colin Nash [MVP]"

>>>1. Cookies aren't necessarily a bad thing. Basically, they are text

>> We've been telling folks "cookies are just text files" for years.
>> And we've been lying...

>> "...a site can choose to store any information in any way
>> in a cookie, including HTML scripting information."

>There are exploits in IE relating to cookies, which have been patched.

Even AFTER patching, scripts can be hidden in cookies, by design.
That means they represent a higher risk than "text files".

>Any scripts embedded are supposed to be treated as if they were
>scripts on the web page itself

Why would one want to facilitate this, given realities such as banner
ads that are common across domains, etc.?

>I'll still say that cookies are generally safe to leave enabled.

I do too - but I no longer claim they are as harmless as "just text
files". If I could trust the OS to not run them as scripts, I'd be
happier, but to rely on a "protection" mechanism that has already
failed and had to be patched, is ungood.

>The more you disable, the more you reduce the attack surface but is
>whether the functionality of cookies is useful enough to keep

Generally I agree, though there is a case to be made for limiting
cookies in various ways, e.g...
- killing cookies from known bad guys, a la Spyware Blaster
- possibly limiting cookies to Trusted Zone
- using a web browser that doesn't run scripts in cookies

I'm also bracing myself for the need to revise this assessment, i.e.
if malware begins to explit cookies as a way of dropping scripts.

>> Even if it is "only" your own LAN that uses F&PS, it's best to avoid
>> full-sharing any code or any part of the startup axis, so that if one
>> PC is infected, infection can't spread to other PCs.

>I agree that disabling file and print sharing, or at least the default drive
>shares, is part of hardening a system. That's why MBSA reports this. My
>original reply was intended to say that what BobW is seeing is the normal
>out-of-the-box configuration for XP Pro and doesn't indicate an exploit

That is true, yes. I don't consider MS duhfaults to be compatible
with safe computing practice, even post-SP2, but your point that these
settings don't indicate interference (unless the user had applied
non-default settings as protection, and this has been reverted) is
well made. IMO, unless you have some dependency on those c$, d$, e$
etc. admin shares, I would most definitely disable them.

There's no way to disable IPC$ beyond the current runtime, and the
associated RPC risk is more effectively managed in other ways
(firewall, patching the RPC service, preventing RPC failures from
restarting the whole system)

>As an aside, most large ISPs block the ports used by Windows file
>sharing from crossing the Internet, but obviously one shouldn't
>rely on this protection.

That's nice to know, and may be a new practice, given Opaserv mileage
(Opaserv spreads purely via F&PS, and spread well) and more recent
mileage (my bro-in-law hooked into his home PC via the Internet from
his iPaq in the field, and that worked via F&PS as recently as 2004).



>--------------- ---- --- -- - - - -
I'm baaaack!
>--------------- ---- --- -- - - - -