Re: Security hole in file sharing (bug?)
From: Roger Abell (mvpNOSpam_at_asu.edu)
Date: 01/29/05
- Next message: Shenan Stanley: "Re: Anti-spyware"
- Previous message: Carey Frisch [MVP]: "Re: how to fix"
- In reply to: Massimo: "Re: Security hole in file sharing (bug?)"
- Next in thread: Massimo: "Re: Security hole in file sharing (bug?)"
- Reply: Massimo: "Re: Security hole in file sharing (bug?)"
- Reply: Massimo: "Re: Security hole in file sharing (bug?)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sat, 29 Jan 2005 09:32:45 -0700
"Massimo" <barone@mclink.it> wrote in message
news:ctg92n$l9k$1@newsreader1.mclink.it...
> "Roger Abell" <mvpNOSpam@asu.edu> ha scritto nel messaggio
> news:%23QitcedBFHA.4004@tk2msftngp13.phx.gbl...
>
> > Anyway, modem dialup from laptop with both MS network
> > client and MS file and print unchecked on the DUN interface
> > connectoid. Then used TS to get remote window (from the
> > same laptop) on box elsewhere from which NetBIOS ports
> > would not be filtered between laptop and remote. Ping
> > check - yep, seeing laptop. Open IE back to IIS on laptop,
> > yep. Map drive \\<dun-ip-of-laptop>\hiddenshare$ and
> > bingo - it mapped.
>
> Ok, so it was not my fault :-)
> It seems to be quite a serious bug; how can I send a bug report to
> Microsoft?
So it would seem.
The public route for reporting is discussed at
https://s.microsoft.com/technet/security/bulletin/alertus.aspx
I will be finding the route to test such that RDP availability
is ruled out, posting internally with MVPs for futher confirms
and experiments, and generally this will likely raise a ruckus in
visible (internally) ways if others see as you have demonstrated.
>
> > Now, what I forgot to try is a three machine test.
> > That is, mapping to laptop from a machine to which there
> > is no RDP term services/remote desktop connection with
> > the laptop. Why? RDP will map drives within the RDP
> > session if configured. I just want to rule this out as an
> > interacting influence here.
>
> I don't think it matters: the RDP client uses NetBIOS to map drives, so if
> it doesn't work due to being disabled on the server, RDP can't possibly
use
> it. Besides, you're establishing a RDP session with the machine from which
> you connect to your shares, so RDP is mapping shares on the *remote*
> machine, if any.
all the same, despite fact that I did use a map network drive, hence a
call to the old Net cmd dll, it is possible that it was intercepted and
instead tunneled inside RDP - possible is enough for me to want to
rule out possibility
> Anyway, you don't need three machines for this test: you only need two
> computers with two modems and two phone lines.
Or just two if one is on LAN beside a (non-digital) telephone
from which one can get a dialup to something that routes to
within that same LAN without and NetBT filtering (it is the
non-digital phone part that is my issue for this setup, hence
my mind had traveled to ways in three box design).
>
> > As you stated in other post, I also know that this did
> > not behave this way before (but I do not believe I have
> > ever known for fact that this is so post SP2 of XP).
>
> Have you looked at this? It says this misbehaviour was introduced in SP1,
> and worsened by SP2 which introduced a similar bug in the built-in
firewall.
> http://www.pcwelt.de/know-how/extras/103039/
>
The last part mentioned we were aware of early on and MS has
now released patch (the do not trust use of "Only local subnet"
exemption choice in the SP 2 firewall). Oddly, the patch was
only released as a critical (IIRC) update through Windows Update
but not as a security bulletin patch. Note that I was testing from
XP SP2 with this patch applied.
This article also states that the exposure exists even with the
XP firewall in use. This I found not true. In my test yesterday
I toggled the firewall on the laptop for the dial-up connection
and it was immediately effective in blocking access from the
RDP client with already existing mapped drive. Toggle firewall
back off and access resumed (note: this despite the fact that
there was a popup saying the change would not be effective
for the current dialup connection due to the in-use condition).
-- Roger
- Next message: Shenan Stanley: "Re: Anti-spyware"
- Previous message: Carey Frisch [MVP]: "Re: how to fix"
- In reply to: Massimo: "Re: Security hole in file sharing (bug?)"
- Next in thread: Massimo: "Re: Security hole in file sharing (bug?)"
- Reply: Massimo: "Re: Security hole in file sharing (bug?)"
- Reply: Massimo: "Re: Security hole in file sharing (bug?)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|