[Vista 64, 3.0.24.368] MAJOR Bug: Port 135 is left open by default

Summary:
Even when using a fresh, default Comodo install with 100% unchanged default options (!),
Port 135 is reported as being OPEN by the www.grc.com ShieldsUP! scanner.

The firewall does not trigger an alert window if there is an incoming connection on Port 135,
it is simply left open, no questions asked.

(Please also see this thread:)
https://forums.comodo.com/help_for_v3/vista_64_rpc_port_135_open_after_default_install-t23231.0.html
The abovementioned thread was the first one posted by me, this thread (the one you are
reading now) is the more current one, so please continue any discussion right here.

best regards,
raynor

Still would liike to see your default application rules posted. Most of us have modified them and don’t know what the current defaults are. I don’t use global rules, but my system related application rules are attached for comparison-and do stealth all the ports. The default rules for Windows Updater Applications should cause a block and log for incoming on port 135 to svchost.exe. Could you also go to D+/common tasks/my protected files/groups and verify that svchost.exe is still listed there under Windows Updater Applications? And that under firewall/common tasks/view active connections that svchost.exe is shown listening on port 135? Do you show anything in your firewall events log?

[attachment deleted by admin]

Now, these are not “my” defaults ;), but these are Comodo’s default rules, as I can reproduce
this behaviour with an 100% default installation without having changed any rules.
At the moment I am using a fresh installation with UNCHANGED rules (both Application & Global
rules).

The only added rule is the automatically added one for Firefox (otherwise I could not post this
message :wink:

See Screenshots 1 & 2 for these default rules.

No, they don’t (see screenshot 1). Comodo’s default setting does NOT have a
Block and Log rule for the windows updater apps.

It is. Not surprisingly, because at the moment I’m testing with a clean, fresh installation of CPF :wink:

It Is. This is Vista’s default behaviour. Also See Screenshot 3.

No. Nothing gets logged. Not surprisingly, too, because there are no block and log rules for svchost.exe.

Again:
The expected behaviour would be that I am asked (via popup firewall alert) when there is
an incoming connection on port 135 (svchost.exe). This is what happens under XP.
There I could then click DENY & Remember, and a deny (block & log) rule for svchost.exe
would be created.
Under Vista 64, The port is simply left open, there is no alert popup, and that is that.

If anyone wants to reproduce the Bug, Please follow exactly these easy :wink: steps:

(You need Windows Vista 64 SP1 (the OS I’m using) & Comodo 3.0.24.368 64 Bit)

  1. Uninstall your old Comodo
    → reboot

  2. Do a clean Comodo install (100% default options, i.e. Firewall and Defense+)
    → reboot

  3. Manually disable the Windows Firewall. Important, as the Comodo installer does not
    do it
    - If the Windows Firewall is still active Port 135 will not be open as it’s blocked
    by the Windows FW (which seems to do a better job at this ;D ;D ;D)

  4. Do NOT touch ANY options of Comodo Firewall. Just leave it on defaults.

  5. Visit www.grc.com, select the ShieldsUP! Scanner, click on “Common Ports”

  6. BAM! Port 135 is open, and the firewall does not trigger an alert (i.e. it does not ask)…
    :-X :-X :-X

[attachment deleted by admin]

Thanks for the info. Agree on the expected “ask” behavior (and that it is an urgent issue); maybe someone else can explain why it didn’t happen in Vista x64. Checked an earlier version and the block and log was not there, so I must have added it. Maybe someone else can check it for Vista x32 since you say it works correctly with XP. :frowning:

First of all, other people should please reproduce this with Vista 64.
This will tell me that I’m not crazy (I dont think I am) and that this is indeed
a (major) bug.

For me It’s dead easy to reproduce (see steps above). I did it heaps of times…

Tests with Vista 32 would also be welcome to see if it’s a 64 Bit issue only.

And yes, under XP, all is well, no problems there :slight_smile:

Waiting for more reports …

OK, verified proper operation with Vista x32. Bypassed router and plugged directly into the computer. With the block and log, stealth as expected. Couldn’t log it because of selective CFP3 logging. Removed the block and log all, and got the expected popup. Shields Up timed out the response and the port was marked “stealth”. So need further inputs from Vista x64 users, perhaps verification form others.

Come on guys, can someone please try to reproduce this bug
with Vista 64 ? Thank you ;). As I said, for me it is dead easy
to reproduce.

Just use a clean, fresh Comodo install with unchanged default settings,
and run a ShieldsUP!“common ports” scan.
There is NO firewall alert prompt (“Incoming connection on Port 135 for svchost.exe”),
but the port is simply open.

Only the “stealth ports wizard” correctly stealths the port (via the
global rules it creates.)

This seems like a major bug. That is why it should be investigated further.
Maybe the developers should also have a look at this.


For better troubleshooting, I’m posting my detailed configuration again:

(… which is nothing special by the way ;))

  • Vista x64 SP1 English, all Windows Updates installed (As of May 2008)
  • Windows Firewall disabled (Service is set to disabled)
  • Comodo 3.0.24.368 - a fresh, clean install, installed with installer’s standard settings
    (= Firewall and D+ enabled). No options changed in the program itself (i.e. no added rules,
    no stealth ports wizard, no nothing).
  • Svchost.exe is Listening to Port 135 (DCOM) - This is Vista’s default behaviour
  • PPoE Broadband ADSL dialup connection (direct connection, no proxy, no router),
    using Vista’s integrated standard PPoE driver. Nothing special.

If anyone needs additional details, or I should run additional test, I’ll be happy
to assist.

I went back to the old version and apparently, everything is working fine now.
Please see this thread:

https://forums.comodo.com/bug_reports/cvtresexe_netframework_99-t23317.0.html;msg164524#msg164524

Cheers
Juan

HP Compaq Quad Core Q6600 2.40 Ghz -all programs+drivers updated-
W Vista Home Premium Sp1 x32
3 Mb Ram
CMF
CBOClean
Nod32 v3
Defense+ in “Clean Pc mode”

I think you posted in the wrong thread. This thread is about a completely different issue.

It is about svchost.exe is shown listening on port 135 , isn´t it?

…<<<<Today I decided to go back to the old 3.0.21.329 version and so far -3 hours later-, everything is working fine.
Even the port 135 seems to be closed now (at least it´s not listed in the “Active conecctions” window: it was “listening” with the new version). Read this report to see what I mean. https://forums.comodo.com/bug_reports/vista_64_3024368_major_bug_port_135_is_left_open_by_default-t23266.0.html

BTW, I don´t have installed the Safesurf, and the firewall is running with the default config.
Regards
Juan

HP Compaq Quad Core Q6600 2.40 Ghz -all programs+drivers updated-
W Vista Home Premium Sp1 x32
3 Mb Ram
CMF
CBOClean
Nod32 v3
Defense+ in “Clean Pc mode”>>>>>

I got my rules manually made to avoid that. Nnngh… this is not good for leaktests~

Yes, you’re right, but to be more exact, it’s about port 135 being open to
the outside world
(in other words: not being shielded / stealthed) by the
firewall. With the default configuration, the firewall should show an
alert window
if there is an incoming connections on port 135),
which it does not, but leaves the post open and unprotected instead.

Svchost.exe is ALWAYS “listening” to port 135, this simply is Windows’s
(both Vista and XP) default configuration. This is not the problem. The question
is if the firewall protects (stealthes) this port or not. Currently, with Vista 64 and
Comodo 3.0.24.368 it FAILS to do so.

This is of course not a solution :wink: A proper firewall MUST NOT leave a port open by
default without asking or require manual configuration to be “safe”.

This is why I labeled this bug as MAJOR. This is not a little glitch, it is serious business :P0l.

All the best,
raynor
This

This still isn’t fixed in 3.0.25.378.

Any news on this one, anyone ???

As I said above, IMHO this is a serious, major bug :P0l :P0l :P0l

I always check grc after an update and never experienced the problem you describe w/ 135. I’m running Vista 64 SP1 with all updates and Avast free Antivirus. I do not mess with any of the firewall and/or antivirus settings - I just leave it at default. I have updated Comodo to 3.0.25.378.

Maybe you can use an SPI firewall router until Comodo gets to the bottom of your problem.

So you do get prompted by the firewall when there is an incoming connection
on port 135 (or I should say “did” because most likely you klicked on deny&remember
there was an incoming connection for svchost.exe) ?

Could you please do me a favor and delete your firewall rule for svchost.exe
and check if you then get prompted again for incoming connections if you run
a grc ShieldsUP! scan ?

Thx,
raynor

I did some more investigations.

For me, no Application rule whatsoever succeeds in closing port 135. Even If I manually
define svchost.exe (The windows system process “listening” to port 135) as a
blocked application (via the “Define a New Blocked Application” Wizard),
port 135 still remains open.

The only way of successfully closing Port 135 is via GLOBAL rules, i.e. by running the
“Stealth Ports” Wizard and selecting “Block all incoming connections - stealth my ports to everyone”

But the “Block all” application rule" for svchost.exe still works at least partially, because it
e.g. blocks all DNS traffic (Port 53)… It just does not close port 135, which it should !

I have attached a screenshot which further illustrates what I just have described.

[attachment deleted by admin]

Hi,

No. There is something wrong with your configuration. First of all, are you using your computer as a gateway or something? Because incoming DNS is not something you should see if you use your computer as a desktop computer.

Stealth my ports to everyone will block INCOMING connections. Not outgoing DNS.

First, please describe your entire networking scenario pls:

1 - How do you connect the Internet? Are you behind a router?
2 - What is the role of your Vista64 PC in your network?
3 - Default configuration, will not ofcourse allow port 135 to be opened. So do you have Windows firewall enabled? If so, please disable it and retry. Because Windows Firewall can mess with the applications significantly.

Egemen

No. There is something wrong with your configuration. First of all, are you using your computer as a gateway or something? Because incoming DNS is not something you should see if you use your computer as a desktop computer.

Stealth my ports to everyone will block INCOMING connections. Not outgoing DNS.

I think there has been a misunderstanding :wink: All I said is that the “Block All” Application Rule
for svchost.exe (which I created only for testing purposes) does prevent svchost.exe from
doing outgoing DNS queries. So far so good (=this rule does work partially).
But this (Testing-) rule should also close Port 135 (becasue it blocks all svchost.exe traffic),
which it does not.
The PC is a normal desktop, not acting as a gateway (see my config below)

I’ll be happy to post my config again:

  • Vista x64 SP1 English, all Windows Updates installed (As of May 2008)

  • Windows Firewall disabled (Service is set to disabled)
    (On a sidenote: If the windows firewall is still enabled, Port 135 is stealthed,
    presumably because the windows firewall does this - If It is disabled (Service stopped),
    this is when Port 135 gets reported as being open).

  • Right now I’m using the new 3.0.25.378 - a fresh, clean install, installed with
    the installer’s standard settings (= Firewall and D+ enabled). For testing purposes,
    No options were changed
    in the program itself (i.e. no added rules, stealth ports
    wizard not yet run, no nothing).

  • Svchost.exe is Listening to Port 135 (DCOM) - This is Vista’s default behaviour

  • PPoE Broadband ADSL dialup connection (direct connection → no router, no gateway),
    using Vista’s integrated standard PPoE driver. Nothing special. Just a direct DSL dialup.
    There is no Network, the PC is hooked directly to the Broadband modem Using PPPoE.

A Little Summary:

Using a default install, without changing any options, I do net get prompted on
incoming connections. The firewall should prompt me the first time when there is
an incoming connection for svchost.exe. This is what happens on my other computer
which has Windows XP installed. But on The Vista 64 PC, there is no alert prompt.
That is the core of the problem (together with the added fact that not even manually
creating an application rule helps).
After I run the stealth my ports wizard, all is well (the created global rules do successfully
stealth port 135). But before that wizard has been run, there should be a prompt on
incoming connections…

If you need further details or want me to perform additional steps, please let me know,
I’d be more than happy to assist.

If you want detailed steps how I succeed every time in replicating the problem,
please see a few posts above in this thread.

All the best,
raynor

Yes. In this scenario, CFP must show an incoming connection alert as it is doing it here. Lets try to pinpoint some possibilities.

Some other application may be listening on port 135 and hence CFP may be detecting it instead of svchost.exe.
1 - Can you please paste the active applications snapshot ?You can use ProcessExplorer from sysinternals.com for this

2 - Can you also please post a screenshot of Active Connections window from CFP->Firewall->View Active Connections

Thx,
egemen

Some other application may be listening on port 135 and hence CFP may be detecting it instead of svchost.exe. 1 - Can you please paste the active applications snapshot ?You can use ProcessExplorer from sysinternals.com for this

2 - Can you also please post a screenshot of Active Connections window from CFP->Firewall->View Active Connections

Below you will find the two requested screenshots.

I don’t think there is another program listening to port 135,
and as far as running applications are concerned, no “special” networking apps are running,
as it is a recently (about 3 weeks ago) newly installed Vista, and it is in fact my mother’s PC
who does not need any special networking programs, I did not install any networking / internet
stuff except firefox which is all she needs :wink:

But see for yourself.

[attachment deleted by admin]