Re: Fw: Serious Security Issue in Windows XP SP2's Firewall

• Previous message: Marc Fossi: "SecurityFocus Microsoft Newsletter #208"
• Maybe in reply to: Thor: "Fw: Serious Security Issue in Windows XP SP2's Firewall"
• Next in thread: Frank Knobbe: "Re: Fw: Serious Security Issue in Windows XP SP2's Firewall"
• Reply: Frank Knobbe: "Re: Fw: Serious Security Issue in Windows XP SP2's Firewall"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

To: "Frank Knobbe" <frank@knobbe.us>, <focus-ms@securityfocus.com>
Date: Tue, 28 Sep 2004 11:59:10 -0700

Hey man! Hope all is doing well-- replies inline as well...

> ----- Original Message -----
> From: "Frank Knobbe" <frank@knobbe.us>
> To: "Thor" <thor@hammerofgod.com>
> Cc: <focus-ms@securityfocus.com>
> Sent: Tuesday, September 28, 2004 9:52 AM
> Subject: Re: Fw: Serious Security Issue in Windows XP SP2's Firewall
>
> Heya Tim,
>
> I'm not trying to bash MS, but I do have a few comments. Please see
> inline.
>
> On Mon, 2004-09-27 at 21:12, Thor wrote:
>> If the system is a domain member, exceptions for F&P Sharing will be
>> enabled
>> for the local subnet. This applies to all interfaces.
>
> Design Flaw #1: While the approach to determine if the PC is used at
> home or in a corporate setting (domain membership) seems like a sensible
> way, the fact that it is treating all interfaces as equal is not.
> Network interfaces, dial-up interfaces and VPN interfaces all have
> different... uhm... levels of trust. I mean, you know where you stick
> your network cable into, but dialing with the RAS adapter to the
> Internet just is not the same. Know what I mean?

Sure-- but remember- this is just the default setting, and a necessary one
if the system is a domain member so that standard "domain" functions are
available. This is not an issue for non-domain systems, and isn't one for
domain systems either, as at roll-out of SP2, you can fully configure the FW
settings. Regarding the RAS adapter dialing into the Internet, in that
case, F&P would not be bound in the first place (when the connection was
created). Each adapter's bindings
are easily changed to what you want, as well as individual exceptions
per-adapter if needed...

>> If
>> Pre-SP2, you had a dial-up interface **that had file and print sharing
>> BOUND
>> to the adapter** but, had the ICF turned on so that the bindings were
>> unreachable, and it was a domain member, and you then installed SP2, the
>> "global" exceptions would be applied and the firewall turned on for all
>> interfaces.
>
> Design Flaw #2: Multiple policies conflict in interface protection. The
> problem here is that you apparently have ICF policies on one hand and
> "exceptions" on the other. These two policy sets conflict. If you
> configure your firewall to block ports, you should not expect a
> different policy to override this. Which policy governs? The
> purposefully set one, or an exception? How do you, as a user or admin,
> know which one is in affect? There is no feedback to the admin that
> displays the "effective" policy, including exceptions.

Not really "multiple policies" conflicting... It is an updated policy
replacing existing policies at install time-- there aren't 2 at the same
time... It's very easy to check out what settings are implemented for the FW
in general, and for each individual adapter...

>
>> [...] people on the local subnet only will
>> not have NB filtered by the firewall. But even so, null connections
>> don't
>> work, and if an account does not have a password, it can't be used for
>> network connections. No world readable, no "blank password access," no
>> issue unless you specifically CREATE the issue on purpose.
>
> That is a very unthoughtful answer which I would not have expected from
> you. Even if null connections are disabled and you don't have a user
> name and password, you still have the annoyance of pop-up spam (yes, you
> could argue that the Messenger and Alerter services are off now by
> default, but that's not the point. Data is accepted, without a password,
> and used by the system).

I really should have been more clear about that- it sounds like "mitigating
factors" junk..
I wasn't trying to sugar coat it-- I was directly responding to the claims
in the article where they said "world readable, no password access" etc...

>
> More important, what about undiscovered buffer overflows in the SMB/CIFS
> protocol handling? Firewalls are not there to protect us from the known
> issues, but from the unknown issues. Firewalls should be configured to
> block all, except allowed ports, not to allow all and block selected
> ports. Are you saying that if your system requires authentication, you
> don't need a firewall? I don't think so.

That's what WF does-- blocks all, except for whatever exceptions you
define...

> Microsoft were to benefit greatly if they take KISS to heart. It seems
> that applying more than one policy (fw policy AND exceptions)
> unnecessarily over-complicates things. Unforeseen consequences can arise
> that hurt the security of a system greatly. Keeping things simple wold
> be in the best interest of security.

There is only one policy- everything is blocked, and you open what you need.
I think some of the other posts may have confused that, but it really is
pretty easy...

Thanks Frank- ttyl

t

---------------------------------------------------------------------------
---------------------------------------------------------------------------

• Previous message: Marc Fossi: "SecurityFocus Microsoft Newsletter #208"
• Maybe in reply to: Thor: "Fw: Serious Security Issue in Windows XP SP2's Firewall"
• Next in thread: Frank Knobbe: "Re: Fw: Serious Security Issue in Windows XP SP2's Firewall"
• Reply: Frank Knobbe: "Re: Fw: Serious Security Issue in Windows XP SP2's Firewall"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]