Security hole in file sharing (bug?)

Archived from groups: microsoft.public.security,microsoft.public.windowsxp.general,microsoft.public.windowsxp.security_admin (More info?)

I don't know if this has already been reported.

I have a Windows XP SP2 computer, fully up-to-date with patches, which
connects to the Internet through a dial-up connection.
In the network settings for the dial-up connection, I have disabled the
"client for Microsoft networks" and "file and print sharing" components, and
I've also disabled NetBIOS on the TCP/IP settings. With this configuration,
I was quite sure my shares wouldn't have been exposed to Internet users...
but I found, instead, that they are. Altough disabled, the file sharing
services are fully accessible, and I was able to connect to them and also
use them (by supplying my username/password).

What's happening here? Are not the connection-specific settings valid
anymore?

This seems to me quite a serious bug!

Massimo

P.S.
I know I can activate the built-in firewall, or stop the server service, or
fully remove the file sharing network component, and so on... but I want to
know why I'm settings things right and they're behaving wrong!
26 answers Last reply
More about security hole file sharing
  1. Archived from groups: microsoft.public.security,microsoft.public.windowsxp.general,microsoft.public.windowsxp.security_admin (More info?)

    "Massimo" <barone@mclink.it> wrote in
    news:#LzUmk#AFHA.2788@TK2MSFTNGP15.phx.gbl:

    > I don't know if this has already been reported.
    >
    > I have a Windows XP SP2 computer, fully up-to-date with patches, which
    > connects to the Internet through a dial-up connection.
    > In the network settings for the dial-up connection, I have disabled
    > the "client for Microsoft networks" and "file and print sharing"
    > components, and I've also disabled NetBIOS on the TCP/IP settings.
    > With this configuration, I was quite sure my shares wouldn't have been
    > exposed to Internet users... but I found, instead, that they are.
    > Altough disabled, the file sharing services are fully accessible, and
    > I was able to connect to them and also use them (by supplying my
    > username/password).
    >
    > What's happening here? Are not the connection-specific settings valid
    > anymore?
    >
    > This seems to me quite a serious bug!
    >
    > Massimo
    >
    > P.S.
    > I know I can activate the built-in firewall, or stop the server
    > service, or fully remove the file sharing network component, and so
    > on... but I want to know why I'm settings things right and they're
    > behaving wrong!
    >

    Massimo,

    I'm sure there is no bug there. Did you post thru a proxy ? The posting
    host header says: adsl203-153-023.mclink.it .AFAIK, dsl is not a dial-up
    connection, but a network connection, either LAN or USB.
  2. Archived from groups: microsoft.public.security,microsoft.public.windowsxp.general,microsoft.public.windowsxp.security_admin (More info?)

    What you report is now what I have experienced.
    How is it that you performed your test?

    --
    Roger Abell
    Microsoft MVP (Windows Security)
    MCSE (W2k3,W2k,Nt4) MCDBA
    "Massimo" <barone@mclink.it> wrote in message
    news:%23LzUmk%23AFHA.2788@TK2MSFTNGP15.phx.gbl...
    > I don't know if this has already been reported.
    >
    > I have a Windows XP SP2 computer, fully up-to-date with patches, which
    > connects to the Internet through a dial-up connection.
    > In the network settings for the dial-up connection, I have disabled the
    > "client for Microsoft networks" and "file and print sharing" components,
    and
    > I've also disabled NetBIOS on the TCP/IP settings. With this
    configuration,
    > I was quite sure my shares wouldn't have been exposed to Internet users...
    > but I found, instead, that they are. Altough disabled, the file sharing
    > services are fully accessible, and I was able to connect to them and also
    > use them (by supplying my username/password).
    >
    > What's happening here? Are not the connection-specific settings valid
    > anymore?
    >
    > This seems to me quite a serious bug!
    >
    > Massimo
    >
    > P.S.
    > I know I can activate the built-in firewall, or stop the server service,
    or
    > fully remove the file sharing network component, and so on... but I want
    to
    > know why I'm settings things right and they're behaving wrong!
    >
  3. Archived from groups: microsoft.public.security,microsoft.public.windowsxp.general,microsoft.public.windowsxp.security_admin (More info?)

    Now or not?? -- Steve

    "Roger Abell" <mvpNOSpam@asu.edu> wrote in message
    news:uk08Xv$AFHA.608@TK2MSFTNGP15.phx.gbl...
    > What you report is now what I have experienced.
    > How is it that you performed your test?
    >
    > --
    > Roger Abell
    > Microsoft MVP (Windows Security)
    > MCSE (W2k3,W2k,Nt4) MCDBA
    > "Massimo" <barone@mclink.it> wrote in message
    > news:%23LzUmk%23AFHA.2788@TK2MSFTNGP15.phx.gbl...
    >> I don't know if this has already been reported.
    >>
    >> I have a Windows XP SP2 computer, fully up-to-date with patches, which
    >> connects to the Internet through a dial-up connection.
    >> In the network settings for the dial-up connection, I have disabled the
    >> "client for Microsoft networks" and "file and print sharing" components,
    > and
    >> I've also disabled NetBIOS on the TCP/IP settings. With this
    > configuration,
    >> I was quite sure my shares wouldn't have been exposed to Internet
    >> users...
    >> but I found, instead, that they are. Altough disabled, the file sharing
    >> services are fully accessible, and I was able to connect to them and also
    >> use them (by supplying my username/password).
    >>
    >> What's happening here? Are not the connection-specific settings valid
    >> anymore?
    >>
    >> This seems to me quite a serious bug!
    >>
    >> Massimo
    >>
    >> P.S.
    >> I know I can activate the built-in firewall, or stop the server service,
    > or
    >> fully remove the file sharing network component, and so on... but I want
    > to
    >> know why I'm settings things right and they're behaving wrong!
    >>
    >
    >
  4. Archived from groups: microsoft.public.security,microsoft.public.windowsxp.general,microsoft.public.windowsxp.security_admin (More info?)

    not
    When will someone make a free context sensitive and
    aware spell/grammar checker for me !!

    --
    Roger
    "Steven L Umbach" <n9rou@nospam-comcast.net> wrote in message
    news:%23kZVDEDBFHA.2156@TK2MSFTNGP10.phx.gbl...
    > Now or not?? -- Steve
    >
    > "Roger Abell" <mvpNOSpam@asu.edu> wrote in message
    > news:uk08Xv$AFHA.608@TK2MSFTNGP15.phx.gbl...
    > > What you report is now what I have experienced.
    > > How is it that you performed your test?
    > >
    > > --
    > > Roger Abell
    > > Microsoft MVP (Windows Security)
    > > MCSE (W2k3,W2k,Nt4) MCDBA
    > > "Massimo" <barone@mclink.it> wrote in message
    > > news:%23LzUmk%23AFHA.2788@TK2MSFTNGP15.phx.gbl...
    > >> I don't know if this has already been reported.
    > >>
    > >> I have a Windows XP SP2 computer, fully up-to-date with patches, which
    > >> connects to the Internet through a dial-up connection.
    > >> In the network settings for the dial-up connection, I have disabled the
    > >> "client for Microsoft networks" and "file and print sharing"
    components,
    > > and
    > >> I've also disabled NetBIOS on the TCP/IP settings. With this
    > > configuration,
    > >> I was quite sure my shares wouldn't have been exposed to Internet
    > >> users...
    > >> but I found, instead, that they are. Altough disabled, the file sharing
    > >> services are fully accessible, and I was able to connect to them and
    also
    > >> use them (by supplying my username/password).
    > >>
    > >> What's happening here? Are not the connection-specific settings valid
    > >> anymore?
    > >>
    > >> This seems to me quite a serious bug!
    > >>
    > >> Massimo
    > >>
    > >> P.S.
    > >> I know I can activate the built-in firewall, or stop the server
    service,
    > > or
    > >> fully remove the file sharing network component, and so on... but I
    want
    > > to
    > >> know why I'm settings things right and they're behaving wrong!
    > >>
    > >
    > >
    >
    >
  5. Archived from groups: microsoft.public.security,microsoft.public.windowsxp.general,microsoft.public.windowsxp.security_admin (More info?)

    When you open network connections/advanced/advanced settings does it show
    file and print sharing disabled [unchecked] for all adapters/protocols
    shown?? Have you rebooted the computer since you disabled fps? --- Steve


    "Massimo" <barone@mclink.it> wrote in message
    news:%23LzUmk%23AFHA.2788@TK2MSFTNGP15.phx.gbl...
    >I don't know if this has already been reported.
    >
    > I have a Windows XP SP2 computer, fully up-to-date with patches, which
    > connects to the Internet through a dial-up connection.
    > In the network settings for the dial-up connection, I have disabled the
    > "client for Microsoft networks" and "file and print sharing" components,
    > and I've also disabled NetBIOS on the TCP/IP settings. With this
    > configuration, I was quite sure my shares wouldn't have been exposed to
    > Internet users... but I found, instead, that they are. Altough disabled,
    > the file sharing services are fully accessible, and I was able to connect
    > to them and also use them (by supplying my username/password).
    >
    > What's happening here? Are not the connection-specific settings valid
    > anymore?
    >
    > This seems to me quite a serious bug!
    >
    > Massimo
    >
    > P.S.
    > I know I can activate the built-in firewall, or stop the server service,
    > or fully remove the file sharing network component, and so on... but I
    > want to know why I'm settings things right and they're behaving wrong!
    >
  6. Archived from groups: microsoft.public.security,microsoft.public.windowsxp.general,microsoft.public.windowsxp.security_admin (More info?)

    "DanS" <t.h.i.s.n.t.h.a.t@a.d.e.l.p.h.i.a..n.e.t> ha scritto nel messaggio
    news:Xns95EAB6A48645Eidispcom@216.196.97.142...

    > I'm sure there is no bug there. Did you post thru a proxy ?

    No. I'm using no proxy.

    > The posting
    > host header says: adsl203-153-023.mclink.it .AFAIK, dsl is not a dial-up
    > connection, but a network connection, either LAN or USB.

    That's not true, either. My DSL connection acts like a dial-up one, meaning
    I have to establish it through a DSL modem. Anyway, I did some tests, and it
    acts the same if I connect through a 56K or ISDN line.

    Massimo
  7. Archived from groups: microsoft.public.security,microsoft.public.windowsxp.general,microsoft.public.windowsxp.security_admin (More info?)

    "Roger Abell" <mvpNOSpam@asu.edu> ha scritto nel messaggio
    news:uk08Xv$AFHA.608@TK2MSFTNGP15.phx.gbl...

    > What you report is now what I have experienced.
    > How is it that you performed your test?

    I just established my connection, through a DSL or modem connection. I
    disabled file/print sharing on the connection, but it seems to be running
    anyway.

    Massimo
  8. Archived from groups: microsoft.public.security,microsoft.public.windowsxp.general,microsoft.public.windowsxp.security_admin (More info?)

    I did mean to write it is _not_ what I have experienced.

    So, with the connection established, and with the two unchecked
    in the properties of the network connectoid for your DSL or
    modem interface, how then did you test to see that the shares
    were accessible? To test this you would have needed to use
    another machine on the network to which the DSL or modem
    connected (or internet as case may be).

    So far I have always found that unchecking these, rebooting for
    good measure, will leave no MS networking available on that
    interface, whether it is ethernet, a demand driven connection,
    Tcp/Ip over firewire, etc. . . .
    --
    Roger Abell
    Microsoft MVP (Windows Server System: Security)
    MCDBA, MCSE W2k3+W2k+Nt4
    "Massimo" <barone@mclink.it> wrote in message
    news:ct9m1i$2tj1$1@newsreader1.mclink.it...
    >
    > "Roger Abell" <mvpNOSpam@asu.edu> ha scritto nel messaggio
    > news:uk08Xv$AFHA.608@TK2MSFTNGP15.phx.gbl...
    >
    >> What you report is now what I have experienced.
    >> How is it that you performed your test?
    >
    > I just established my connection, through a DSL or modem connection. I
    > disabled file/print sharing on the connection, but it seems to be running
    > anyway.
    >
    > Massimo
    >
  9. Archived from groups: microsoft.public.security,microsoft.public.windowsxp.general,microsoft.public.windowsxp.security_admin (More info?)

    "Roger Abell [MVP]" <mvpNoSpam@asu.edu> ha scritto nel messaggio
    news:e2XEDwCBFHA.2180@TK2MSFTNGP10.phx.gbl...

    >I did mean to write it is _not_ what I have experienced.

    Ok, sorry.

    > So, with the connection established, and with the two unchecked
    > in the properties of the network connectoid for your DSL or
    > modem interface, how then did you test to see that the shares
    > were accessible? To test this you would have needed to use
    > another machine on the network to which the DSL or modem
    > connected (or internet as case may be).

    That was exactly what I did. I connected with Remote Desktop to another
    machine on the Internet and from that used Windows Explorer to connect to
    \\my.public.ip.address\C$.
    It asked for username and password and then worked flawlessly...

    > So far I have always found that unchecking these, rebooting for
    > good measure, will leave no MS networking available on that
    > interface, whether it is ethernet, a demand driven connection,
    > Tcp/Ip over firewire, etc. . . .

    I was, too, quite sure about this.
    But it seems not to be the case anymore...
    Can you test this again on a XP SP2 machine (maybe the bug was introduced
    with some patch)?

    Massimo
  10. Archived from groups: microsoft.public.security,microsoft.public.windowsxp.general,microsoft.public.windowsxp.security_admin (More info?)

    "Steven L Umbach" <n9rou@nospam-comcast.net> ha scritto nel messaggio
    news:e4lr5LDBFHA.3708@TK2MSFTNGP14.phx.gbl...

    > When you open network connections/advanced/advanced settings
    > does it show file and print sharing disabled [unchecked] for all
    > adapters/protocols shown??

    Not for *every* adapter. I also have a LAN connection, which uses (of
    course!) file and print sharing. On this computer, I also created some VPN
    connection in order to access my office LAN, and I have file/print sharing
    enabled on these, too.
    But I disabled all Microsoft networking (including NetBIOS) on the Internet
    connection.

    > Have you rebooted the computer since you disabled fps?

    I've had it always disabled on that connection; hey, it's the Internet one
    :-)
    And I can remember quite clearly it wasn't working, some months ago... when
    I was in need for it, of course :-)
    So I'm guessing it's a SP/patch-introduced problem.

    Massimo
  11. Archived from groups: microsoft.public.security,microsoft.public.windowsxp.general,microsoft.public.windowsxp.security_admin (More info?)

    What I would try is to disable it on every adapter to see if that makes a
    difference. While connected you could also use the netstat -n command to
    view which IP address is using FPS either via port 139 or 445 TCP. After
    verifying the IP address, check your network adapters to find that IP
    address [ipconfig /all may help here] and check to see if it shows FPS
    enabled or not. To further verify results I would physically remove all
    other network adapters, and the VPN, to leave just the single adapter for
    the internet connection and try to connect again after verifying that file
    and print sharing is disabled and after a reboot. If it still works,
    uninstall file and print sharing to see what happens. --- Steve


    "Massimo" <barone@mclink.it> wrote in message
    news:ctar77$1fs2$1@newsreader2.mclink.it...
    > "Steven L Umbach" <n9rou@nospam-comcast.net> ha scritto nel messaggio
    > news:e4lr5LDBFHA.3708@TK2MSFTNGP14.phx.gbl...
    >
    >> When you open network connections/advanced/advanced settings
    >> does it show file and print sharing disabled [unchecked] for all
    >> adapters/protocols shown??
    >
    > Not for *every* adapter. I also have a LAN connection, which uses (of
    > course!) file and print sharing. On this computer, I also created some VPN
    > connection in order to access my office LAN, and I have file/print sharing
    > enabled on these, too.
    > But I disabled all Microsoft networking (including NetBIOS) on the
    > Internet connection.
    >
    >> Have you rebooted the computer since you disabled fps?
    >
    > I've had it always disabled on that connection; hey, it's the Internet one
    > :-)
    > And I can remember quite clearly it wasn't working, some months ago...
    > when I was in need for it, of course :-)
    > So I'm guessing it's a SP/patch-introduced problem.
    >
    > Massimo
    >
  12. Archived from groups: microsoft.public.security,microsoft.public.windowsxp.general,microsoft.public.windowsxp.security_admin (More info?)

    "Steven L Umbach" <n9rou@n0-spam-for-me-comcast.net> ha scritto nel
    messaggio news:Oe-dnT9qtfxRv2TcRVn-1Q@comcast.com...

    > What I would try is to disable it on every adapter to see if that makes a
    > difference.

    It does (of course!), but I'm complaining here about the OS giving you the
    option for disabling it on a single adapter basis, and then *just ignoring
    it*.

    > While connected you could also use the netstat -n command to view which IP
    > address is using FPS either via port 139 or 445 TCP. After verifying the
    > IP address, check your network adapters to find that IP address [ipconfig
    > /all may help here] and check to see if it shows FPS enabled or not. To
    > further verify results I would physically remove all other network
    > adapters, and the VPN, to leave just the single adapter for the internet
    > connection and try to connect again after verifying that file and print
    > sharing is disabled and after a reboot. If it still works, uninstall file
    > and print sharing to see what happens. --- Steve

    I know lots of ways to prevent it from sharing everything to the outside
    world... I just would like to know why it doesn't work anymore like it used
    to (i.e., with different settings for each adapter).

    This also seems to be quite related to this issue:

    http://www.pcwelt.de/know-how/extras/103039/


    Massimo
  13. Archived from groups: microsoft.public.security,microsoft.public.windowsxp.general,microsoft.public.windowsxp.security_admin (More info?)

    I am just trying to help you track down what is going on and verify that FPS
    is disabled on the proper adapter. In my experience, it does work when
    disabled on a particular adapter. --- Steve


    "Massimo" <barone@mclink.it> wrote in message
    news:ctbi82$t7i$1@newsreader1.mclink.it...
    > "Steven L Umbach" <n9rou@n0-spam-for-me-comcast.net> ha scritto nel
    > messaggio news:Oe-dnT9qtfxRv2TcRVn-1Q@comcast.com...
    >
    >> What I would try is to disable it on every adapter to see if that makes a
    >> difference.
    >
    > It does (of course!), but I'm complaining here about the OS giving you the
    > option for disabling it on a single adapter basis, and then *just ignoring
    > it*.
    >
    >> While connected you could also use the netstat -n command to view which
    >> IP address is using FPS either via port 139 or 445 TCP. After verifying
    >> the IP address, check your network adapters to find that IP address
    >> [ipconfig /all may help here] and check to see if it shows FPS enabled or
    >> not. To further verify results I would physically remove all other
    >> network adapters, and the VPN, to leave just the single adapter for the
    >> internet connection and try to connect again after verifying that file
    >> and print sharing is disabled and after a reboot. If it still works,
    >> uninstall file and print sharing to see what happens. --- Steve
    >
    > I know lots of ways to prevent it from sharing everything to the outside
    > world... I just would like to know why it doesn't work anymore like it
    > used to (i.e., with different settings for each adapter).
    >
    > This also seems to be quite related to this issue:
    >
    > http://www.pcwelt.de/know-how/extras/103039/
    >
    >
    > Massimo
    >
  14. Archived from groups: microsoft.public.security,microsoft.public.windowsxp.general,microsoft.public.windowsxp.security_admin (More info?)

    I don't think it'll help you in this situation.

    The fault lies in the English language, and the similarity between the words
    "not" and "now", in their spelling and in their allowed placements.
    Consider the two sentences:

    I will now insult your parental lineage.
    I will not insult your parental lineage.

    Either is contextually correct, at least up until a subsequent line, wherein
    it'd be clear as to whether I was, or was not, crafting a rude retort.

    Clearly the English language needs to be changed. I'll suggest it for a
    future service pack.

    Alun.
    ~~~~
    --
    Software Design Engineer, Internet Information Server (FTP)
    This posting is provided "AS IS" with no warranties, and confers no rights.

    "Roger Abell" <mvpNOSpam@asu.edu> wrote in message
    news:efNFUrDBFHA.1524@TK2MSFTNGP09.phx.gbl...
    > not
    > When will someone make a free context sensitive and
    > aware spell/grammar checker for me !!
    >
    > --
    > Roger
    > "Steven L Umbach" <n9rou@nospam-comcast.net> wrote in message
    > news:%23kZVDEDBFHA.2156@TK2MSFTNGP10.phx.gbl...
    >> Now or not?? -- Steve
    >>
    >> "Roger Abell" <mvpNOSpam@asu.edu> wrote in message
    >> news:uk08Xv$AFHA.608@TK2MSFTNGP15.phx.gbl...
    >> > What you report is now what I have experienced.
    >> > How is it that you performed your test?
    >> >
    >> > --
    >> > Roger Abell
    >> > Microsoft MVP (Windows Security)
    >> > MCSE (W2k3,W2k,Nt4) MCDBA
    >> > "Massimo" <barone@mclink.it> wrote in message
    >> > news:%23LzUmk%23AFHA.2788@TK2MSFTNGP15.phx.gbl...
    >> >> I don't know if this has already been reported.
    >> >>
    >> >> I have a Windows XP SP2 computer, fully up-to-date with patches, which
    >> >> connects to the Internet through a dial-up connection.
    >> >> In the network settings for the dial-up connection, I have disabled
    >> >> the
    >> >> "client for Microsoft networks" and "file and print sharing"
    > components,
    >> > and
    >> >> I've also disabled NetBIOS on the TCP/IP settings. With this
    >> > configuration,
    >> >> I was quite sure my shares wouldn't have been exposed to Internet
    >> >> users...
    >> >> but I found, instead, that they are. Altough disabled, the file
    >> >> sharing
    >> >> services are fully accessible, and I was able to connect to them and
    > also
    >> >> use them (by supplying my username/password).
    >> >>
    >> >> What's happening here? Are not the connection-specific settings valid
    >> >> anymore?
    >> >>
    >> >> This seems to me quite a serious bug!
    >> >>
    >> >> Massimo
    >> >>
    >> >> P.S.
    >> >> I know I can activate the built-in firewall, or stop the server
    > service,
    >> > or
    >> >> fully remove the file sharing network component, and so on... but I
    > want
    >> > to
    >> >> know why I'm settings things right and they're behaving wrong!
    >> >>
    >> >
    >> >
    >>
    >>
    >
    >
  15. Archived from groups: microsoft.public.security,microsoft.public.windowsxp.general,microsoft.public.windowsxp.security_admin (More info?)

    "Steven L Umbach" <n9rou@nospam-comcast.net> ha scritto nel messaggio
    news:uc4KK%23PBFHA.3588@TK2MSFTNGP11.phx.gbl...

    >I am just trying to help you track down what is going on and verify that
    >FPS is disabled on the proper adapter. In my experience, it does work when
    >disabled on a particular adapter.

    Well, it definitely shouldn't!
    And I remeber it actually used to *not* work on a specific adapter, when
    disabled.

    Massimo
  16. Archived from groups: microsoft.public.security,microsoft.public.windowsxp.general,microsoft.public.windowsxp.security_admin (More info?)

    Thanks Alun. I was hoping that adding that "and aware" to
    emphasize that a purely context sensitive parse would be
    insufficient would instill a sense of urgent need. However,
    perhaps I should instead have provided a scoping delimiter
    for the context, that the parse should not just consider context
    in left-right order, as a simple "suggestion" for future service
    pack is perhap of insufficient priority relative to the urgency
    of need.

    --
    Roger Abell

    "Alun Jones [MSFT]" <alunj@online.microsoft.com> wrote in message
    news:%23lJrWYXBFHA.2640@TK2MSFTNGP14.phx.gbl...
    > I don't think it'll help you in this situation.
    >
    > The fault lies in the English language, and the similarity between the
    words
    > "not" and "now", in their spelling and in their allowed placements.
    > Consider the two sentences:
    >
    > I will now insult your parental lineage.
    > I will not insult your parental lineage.
    >
    > Either is contextually correct, at least up until a subsequent line,
    wherein
    > it'd be clear as to whether I was, or was not, crafting a rude retort.
    >
    > Clearly the English language needs to be changed. I'll suggest it for a
    > future service pack.
    >
    > Alun.
    > ~~~~
    > --
    > Software Design Engineer, Internet Information Server (FTP)
    > This posting is provided "AS IS" with no warranties, and confers no
    rights.
    >
    > "Roger Abell" <mvpNOSpam@asu.edu> wrote in message
    > news:efNFUrDBFHA.1524@TK2MSFTNGP09.phx.gbl...
    > > not
    > > When will someone make a free context sensitive and
    > > aware spell/grammar checker for me !!
    > >
    > > --
    > > Roger
    > > "Steven L Umbach" <n9rou@nospam-comcast.net> wrote in message
    > > news:%23kZVDEDBFHA.2156@TK2MSFTNGP10.phx.gbl...
    > >> Now or not?? -- Steve
    > >>
    > >> "Roger Abell" <mvpNOSpam@asu.edu> wrote in message
    > >> news:uk08Xv$AFHA.608@TK2MSFTNGP15.phx.gbl...
    > >> > What you report is now what I have experienced.
    > >> > How is it that you performed your test?
    > >> >
    > >> > --
    > >> > Roger Abell
    > >> > Microsoft MVP (Windows Security)
    > >> > MCSE (W2k3,W2k,Nt4) MCDBA
    > >> > "Massimo" <barone@mclink.it> wrote in message
    > >> > news:%23LzUmk%23AFHA.2788@TK2MSFTNGP15.phx.gbl...
    > >> >> I don't know if this has already been reported.
    > >> >>
    > >> >> I have a Windows XP SP2 computer, fully up-to-date with patches,
    which
    > >> >> connects to the Internet through a dial-up connection.
    > >> >> In the network settings for the dial-up connection, I have disabled
    > >> >> the
    > >> >> "client for Microsoft networks" and "file and print sharing"
    > > components,
    > >> > and
    > >> >> I've also disabled NetBIOS on the TCP/IP settings. With this
    > >> > configuration,
    > >> >> I was quite sure my shares wouldn't have been exposed to Internet
    > >> >> users...
    > >> >> but I found, instead, that they are. Altough disabled, the file
    > >> >> sharing
    > >> >> services are fully accessible, and I was able to connect to them and
    > > also
    > >> >> use them (by supplying my username/password).
    > >> >>
    > >> >> What's happening here? Are not the connection-specific settings
    valid
    > >> >> anymore?
    > >> >>
    > >> >> This seems to me quite a serious bug!
    > >> >>
    > >> >> Massimo
    > >> >>
    > >> >> P.S.
    > >> >> I know I can activate the built-in firewall, or stop the server
    > > service,
    > >> > or
    > >> >> fully remove the file sharing network component, and so on... but I
    > > want
    > >> > to
    > >> >> know why I'm settings things right and they're behaving wrong!
    > >> >>
    > >> >
    > >> >
    > >>
    > >>
    > >
    > >
    >
    >
  17. Archived from groups: microsoft.public.security,microsoft.public.windowsxp.general,microsoft.public.windowsxp.security_admin (More info?)

    Oh my. How embarassing (for MS).

    It has taken me a while to find the time with the setup to
    try this, but yes, I can reproduce what you are reporting.
    I used my laptop (needed to wait until I could reboot it,
    as I hibernate with long-lived projects for weeks at a time).

    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.

    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 have to figure out where
    I need to be for that test, including knowing that NetBIOS
    ports will be available between all.)

    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).

    --
    Roger Abell
    Microsoft MVP (Windows Security)
    MCSE (W2k3,W2k,Nt4) MCDBA
    "Massimo" <barone@mclink.it> wrote in message
    news:ctar0k$1fnj$1@newsreader2.mclink.it...
    > "Roger Abell [MVP]" <mvpNoSpam@asu.edu> ha scritto nel messaggio
    > news:e2XEDwCBFHA.2180@TK2MSFTNGP10.phx.gbl...
    >
    > >I did mean to write it is _not_ what I have experienced.
    >
    > Ok, sorry.
    >
    > > So, with the connection established, and with the two unchecked
    > > in the properties of the network connectoid for your DSL or
    > > modem interface, how then did you test to see that the shares
    > > were accessible? To test this you would have needed to use
    > > another machine on the network to which the DSL or modem
    > > connected (or internet as case may be).
    >
    > That was exactly what I did. I connected with Remote Desktop to another
    > machine on the Internet and from that used Windows Explorer to connect to
    > \\my.public.ip.address\C$.
    > It asked for username and password and then worked flawlessly...
    >
    > > So far I have always found that unchecking these, rebooting for
    > > good measure, will leave no MS networking available on that
    > > interface, whether it is ethernet, a demand driven connection,
    > > Tcp/Ip over firewire, etc. . . .
    >
    > I was, too, quite sure about this.
    > But it seems not to be the case anymore...
    > Can you test this again on a XP SP2 machine (maybe the bug was introduced
    > with some patch)?
    >
    > Massimo
    >
  18. Archived from groups: microsoft.public.security,microsoft.public.windowsxp.general,microsoft.public.windowsxp.security_admin (More info?)

    Evidently sometimes we know more than we actually know.

    I now see that I did mean now and not not :-)

    --
    Roger
    "Roger Abell" <mvpNOSpam@asu.edu> wrote in message
    news:efNFUrDBFHA.1524@TK2MSFTNGP09.phx.gbl...
    > not
    > When will someone make a free context sensitive and
    > aware spell/grammar checker for me !!
    >
    > --
    > Roger
    > "Steven L Umbach" <n9rou@nospam-comcast.net> wrote in message
    > news:%23kZVDEDBFHA.2156@TK2MSFTNGP10.phx.gbl...
    > > Now or not?? -- Steve
    > >
    > > "Roger Abell" <mvpNOSpam@asu.edu> wrote in message
    > > news:uk08Xv$AFHA.608@TK2MSFTNGP15.phx.gbl...
    > > > What you report is now what I have experienced.
    > > > How is it that you performed your test?
    > > >
    > > > --
    > > > Roger Abell
    > > > Microsoft MVP (Windows Security)
    > > > MCSE (W2k3,W2k,Nt4) MCDBA
    > > > "Massimo" <barone@mclink.it> wrote in message
    > > > news:%23LzUmk%23AFHA.2788@TK2MSFTNGP15.phx.gbl...
    > > >> I don't know if this has already been reported.
    > > >>
    > > >> I have a Windows XP SP2 computer, fully up-to-date with patches,
    which
    > > >> connects to the Internet through a dial-up connection.
    > > >> In the network settings for the dial-up connection, I have disabled
    the
    > > >> "client for Microsoft networks" and "file and print sharing"
    > components,
    > > > and
    > > >> I've also disabled NetBIOS on the TCP/IP settings. With this
    > > > configuration,
    > > >> I was quite sure my shares wouldn't have been exposed to Internet
    > > >> users...
    > > >> but I found, instead, that they are. Altough disabled, the file
    sharing
    > > >> services are fully accessible, and I was able to connect to them and
    > also
    > > >> use them (by supplying my username/password).
    > > >>
    > > >> What's happening here? Are not the connection-specific settings valid
    > > >> anymore?
    > > >>
    > > >> This seems to me quite a serious bug!
    > > >>
    > > >> Massimo
    > > >>
    > > >> P.S.
    > > >> I know I can activate the built-in firewall, or stop the server
    > service,
    > > > or
    > > >> fully remove the file sharing network component, and so on... but I
    > want
    > > > to
    > > >> know why I'm settings things right and they're behaving wrong!
    > > >>
    > > >
    > > >
    > >
    > >
    >
    >
  19. Archived from groups: microsoft.public.security,microsoft.public.windowsxp.general,microsoft.public.windowsxp.security_admin (More info?)

    "Roger Abell" <mvpNOSpam@asu.edu> ha scritto nel messaggio
    news:%23QitcedBFHA.4004@tk2msftngp13.phx.gbl...

    > It has taken me a while to find the time with the setup to
    > try this, but yes, I can reproduce what you are reporting.
    > I used my laptop (needed to wait until I could reboot it,
    > as I hibernate with long-lived projects for weeks at a time).
    >
    > 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?

    > 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.
    Anyway, you don't need three machines for this test: you only need two
    computers with two modems and two phone lines.

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

    Massimo
  20. Archived from groups: microsoft.public.security,microsoft.public.windowsxp.general,microsoft.public.windowsxp.security_admin (More info?)

    "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
  21. Archived from groups: microsoft.public.security,microsoft.public.windowsxp.general,microsoft.public.windowsxp.security_admin (More info?)

    "Roger Abell" <mvpNOSpam@asu.edu> ha scritto nel messaggio
    news:%234Lv4%23hBFHA.2876@TK2MSFTNGP12.phx.gbl...

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

    I'll have a look at this.

    >> 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, I *never* use the "map network drives" feature of RDP; so it's
    definitely not involved here.

    > 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).

    No, it states there's a bug in the firewall: if you enable exceptions for
    the NetBIOS ports on the internal LAN interface (or any else), it enables
    them for *every* connections. So you can't (again!) set options at the
    adapter level, but only for the whole system.

    Massimo
  22. Archived from groups: microsoft.public.security,microsoft.public.windowsxp.general,microsoft.public.windowsxp.security_admin (More info?)

    I read it as indicating two separate issues with the firewall.
    And they do say
    <quote>
    Due to the bug carried over from SP1 as well as a new bug, the firewall
    configuration with SP2 has a catastrophic effect.
    </quote>
    and then go on to describe the workaround to the now patched
    "Local subnet only" exception erroneous handling.
    I have the patch for that installed, and am not using any exemption
    for network sharing in the firewall definitions, and I do find that
    the firewall is effective in blocking the sharing.
    So, as far as the article goes, I am not totally sure what they are
    trying to indicate - that you can end up as safe as with XP SP1 -
    but initially they say there was error back in SP1.

    Anyway . . .
    --
    Roger
    --
    Roger Abell
    Microsoft MVP (Windows Security)
    MCSE (W2k3,W2k,Nt4) MCDBA
    "Massimo" <barone@mclink.it> wrote in message
    news:ctgmmb$2aj0$1@newsreader2.mclink.it...
    > "Roger Abell" <mvpNOSpam@asu.edu> ha scritto nel messaggio
    > news:%234Lv4%23hBFHA.2876@TK2MSFTNGP12.phx.gbl...
    >
    > > 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.
    >
    > I'll have a look at this.
    >
    > >> 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, I *never* use the "map network drives" feature of RDP; so it's
    > definitely not involved here.
    >
    > > 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).
    >
    > No, it states there's a bug in the firewall: if you enable exceptions for
    > the NetBIOS ports on the internal LAN interface (or any else), it enables
    > them for *every* connections. So you can't (again!) set options at the
    > adapter level, but only for the whole system.
    >
    > Massimo
    >
  23. Archived from groups: microsoft.public.security,microsoft.public.windowsxp.general,microsoft.public.windowsxp.security_admin (More info?)

    "Roger Abell" <mvpNOSpam@asu.edu> ha scritto nel messaggio
    news:%234Lv4%23hBFHA.2876@TK2MSFTNGP12.phx.gbl...

    > The public route for reporting is discussed at
    > https://s.microsoft.com/technet/security/bulletin/alertus.aspx

    I just submitted the bug report.

    Massimo
  24. Archived from groups: microsoft.public.security,microsoft.public.windowsxp.general,microsoft.public.windowsxp.security_admin (More info?)

    "Roger Abell" <mvpNOSpam@asu.edu> ha scritto nel messaggio
    news:e27%23T9kBFHA.3528@tk2msftngp13.phx.gbl...

    > Evidently sometimes we know more than we actually know.
    >
    > I now see that I did mean now and not not :-)

    Do you have any lottery number that keeps popping up in your toughts? ;-)

    Massimo
  25. Archived from groups: microsoft.public.security,microsoft.public.windowsxp.general,microsoft.public.windowsxp.security_admin (More info?)

    "Massimo" <barone@mclink.it> wrote in message
    news:%23pdfhClBFHA.2012@TK2MSFTNGP15.phx.gbl...
    > "Roger Abell" <mvpNOSpam@asu.edu> ha scritto nel messaggio
    > news:e27%23T9kBFHA.3528@tk2msftngp13.phx.gbl...
    >
    > > Evidently sometimes we know more than we actually know.
    > >
    > > I now see that I did mean now and not not :-)
    >
    > Do you have any lottery number that keeps popping up in your toughts? ;-)
    >


    I wish.

    FYI
    I have now ruled out any RDP interaction.
    Also, it seems that the share access is happening over tcp 445, the
    direct hosting port introduced with W2k. This does not happen for
    non dialup interfaces when MS File and Print is not bound to them.
    --
    Roger
  26. Archived from groups: microsoft.public.security,microsoft.public.windowsxp.general,microsoft.public.windowsxp.security_admin (More info?)

    "Roger Abell" <mvpNOSpam@asu.edu> ha scritto nel messaggio
    news:%23h0tlvCCFHA.2032@tk2msftngp13.phx.gbl...

    > I have now ruled out any RDP interaction.
    > Also, it seems that the share access is happening over tcp 445, the
    > direct hosting port introduced with W2k. This does not happen for
    > non dialup interfaces when MS File and Print is not bound to them.

    I've submitted a security hole bug report to MS using the web form, but
    still no reply :-/

    Massimo
Ask a new question

Read More

Security Microsoft Dial Up Connection Windows XP