On Sat, 15 Oct 2005 02:40:40 -0400, "Colin Nash [MVP]"
>"BobW" <BobW@discussions.microsoft.com> wrote in message

>1. Cookies aren't necessarily a bad thing. Basically, they are text files
>that web sites can save on your hard drive and only that site is able to
>access the file.

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

"By design, it is left to the web site to determine what
information to store in a cookie and how to store it. Because
of this, a site can choose to store any information in any way
in a cookie, including HTML scripting information."

See:

http://www.microsoft.com/technet/sec.../MS02-015.mspx

http://www.microsoft.com/technet/sec.../MS02-023.mspx

http://www.ciac.org/ciac/bulletins/m-063.shtml

....as per Google(cookies microsoft.com patch Internet Zone)

>2. Those shares are completely normal and are usually left alone. Only
>people who know the name and password to an "administrator"-level account on
>the system can access the C$, E$ etc drive shares

Passwords are a pathetically weak defense, especially for "services"
for which no legitimate use exists (as applies when one has a
stand-alone system, to which NO "remote admin" should gain access):
- passwords can be cracked
- malware can tail in via some already-logged-in process

> file sharing usually will not work over the Internet (especially if you
> have a firewall.) So it's a concern only if you have other systems
> on a local network.

Concerns arise if you are forced to bind File and Print Sharing to the
network adapter that leads to the Internet (e.g. one PC is Internet
Connection Sharing host, through which other PCs access the 'net via
the same LAN card used for F&PS), or if your LAN is not cable-bound
(i.e. WiFi, Bluetooth, IR, etc.)

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'm baaaack!
>--------------- ---- --- -- - - - -

"cquirke (MVP Windows shell/user)" <cquirkenews@nospam.mvps.org> wrote in
message news:u2s4l117df81io5qvjf2uichfhhnsq6bhh@4ax.com...
> On Sat, 15 Oct 2005 02:40:40 -0400, "Colin Nash [MVP]"
>
>>1. Cookies aren't necessarily a bad thing. Basically, they are text
>>files
>>that web sites can save on your hard drive and only that site is able to
>>access the file.
>
> We've been telling folks "cookies are just text files" for years.
> And we've been lying...
>
> "By design, it is left to the web site to determine what
> information to store in a cookie and how to store it. Because
> of this, a site can choose to store any information in any way
> in a cookie, including HTML scripting information."
>
> See:
>
> http://www.microsoft.com/technet/sec.../MS02-015.mspx
>
> http://www.microsoft.com/technet/sec.../MS02-023.mspx
>
> http://www.ciac.org/ciac/bulletins/m-063.shtml
>
> ...as per Google(cookies microsoft.com patch Internet Zone)
>


True, there are some exploits in IE relating to cookies, which have been
patched. (Although they are text files, regardless of the contents. Any
scripts embedded are supposed to be treated as if they were scripts on the
web page itself, and there were some exploits that got around this.)... but
I'll still say that cookies are generally safe to leave enabled. Yes, the
more you disable, the more you reduce the attack surface but the question is
whether the functionality of cookies is useful enough to keep. I think it
is.



>>2. Those shares are completely normal and are usually left alone. Only
>>people who know the name and password to an "administrator"-level account
>>on
>>the system can access the C$, E$ etc drive shares
>
> Passwords are a pathetically weak defense, especially for "services"
> for which no legitimate use exists (as applies when one has a
> stand-alone system, to which NO "remote admin" should gain access):
> - passwords can be cracked
> - malware can tail in via some already-logged-in process
>
>> file sharing usually will not work over the Internet (especially if you
>> have a firewall.) So it's a concern only if you have other systems
>> on a local network.
>
> Concerns arise if you are forced to bind File and Print Sharing to the
> network adapter that leads to the Internet (e.g. one PC is Internet
> Connection Sharing host, through which other PCs access the 'net via
> the same LAN card used for F&PS), or if your LAN is not cable-bound
> (i.e. WiFi, Bluetooth, IR, etc.)
>
> 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 or
problem right now. 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.

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!
>--------------- ---- --- -- - - - -