SAS Open Ports

[Rainwalker]

Long after ( at least 5 minutes ) i receive the update there are still at least four ports established with SAS......this ONLY happens with SAS updates and no others ???
Uncomfortable

[Stijnson]

Which version of SAS? Free or Pro? And how do you check this?

[SinisterSam]

i believe you mean 'active connections' rather than 'open ports'. they should time out and close after a period of inactivity.

what are you monitoring the connections with? = port explorer?

[Rainwalker]

I am using paid for version. The ports are not on a Time Wait status as one would expect, but 'Established' and for an inordinate amount of time. This has been the case for many weeks, although it stopped behaving this way after my post.

[G1111]

Just checked using version 4.0.1138 and my database was up to date. The connections all closed down within a few seconds of the answer back from SAS server. Does this occur on yours when you have an update or anytime you check updates. I have mine set to manual updates only.

[Meriadoc]

If SAS auto updates then fine. If I initiate an update they stay on Established until I close the no update window or until SAS finishes the updating then they stay on Close_Wait forever unless I exit the program. (Nick I've asked about this awhile back)

Port Explorer 20 mins after an update...

[Stem]

-{ Quote: "If SAS auto updates then fine. If I initiate an update they stay on Established until I close the no update window or until SAS finishes the updating then they stay on Close_Wait forever unless I exit the program. " }-The Close_wait is showing that the program as received a FIN from server (to close connection) but the OS is waiting for the program to actually close its connection (There is no time_out to this that I know of anymore, so it will remain in this state until the actual application closes (or forced to close by user) the connection.

It would indicate a problem/bug.

[Rainwalker]

I receive updates manually. Just now i allowed the connection to remain established for a full three minutes before manually closing it. There is no Close_Wait time. Occasionally the connection will behave as it should, but not very often. and again, i have only seen this behavior w/SAS.

[Stem]

-{ Quote: "I receive updates manually. Just now i allowed the connection to remain established for a full three minutes before manually closing it. There is no Close_Wait time. Occasionally the connection will behave as it should, but not very often. and again, i have only seen this behavior w/SAS." }-Establised connections do have a timeout, but I need to check as there are various. Normally, established connections are terminated by Program/server.

EDIT:
Have these problems been reported directly to vendor?

[Rainwalker]

-{ Quote: "Establised connections do have a timeout, but I need to check as there are various. Normally, established connections are terminated by Program/server" }-
OK...
btw..good morning

[Stem]

Yes, good morning.

I will try to find time later to look at this on VM,...

EDIT:

I can take an hour now to look at this, I will download the "Free Version" and check the connections/timeouts made,

[fcukdat]

-{ Quote: "Have these problems been reported directly to vendor?" }-

I will give Nick a mail @SAS HQ.

[Stem]

Sorry, I cannot check this today,... have been interrupted/called away. I will look at this as soon as I can.

Regards,

[Rainwalker]

-{ Quote: "Sorry, I cannot check this today,... have been interrupted/called away. I will look at this as soon as I can.

Regards," }-
OK....i have not reported to vendor. I check in here before reporting problems.

[Stem]

I have installed SAS (free version), it did close all connections correctly after the initial update.

I will leave it installed for a day or 2 to keep a check.

[It is currently listening on localhost UDP 1077.]

[Stem]

-{ Quote: "I receive updates manually. Just now i allowed the connection to remain established for a full three minutes before manually closing it. There is no Close_Wait time. Occasionally the connection will behave as it should, but not very often. and again, i have only seen this behavior w/SAS." }-
Just to clarify,

Was it the main program that kept the connection, or was it the SSUPDATE.exe that is in the temp folders.

[Stem]

After a re-boot I am now seeing the same as reported.

The connection is being left active.
The end of data is acknowledge, but the program is not then sending a ack/rst to close the connection.

It does need reporting to vendor.

[Rainwalker]

-{ Quote: "Just to clarify,

Was it the main program that kept the connection, or was it the SSUPDATE.exe that is in the temp folders." }-
Both
I saw your post #17 Stem.....for the time being i have dropped the program.......i would think he has seen this thread.
Thank you for your concern.

[Stijnson]

Does this also happen with the 3.9 version or is it just the 3.9 version that does this?

[Rainwalker]

-{ Quote: "Does this also happen with the 3.9 version or is it just the 3.9 version that does this?" }-
The programs i was using were the last four betas.

[Stijnson]

-{ Quote: "The programs i was using were the last four betas." }-

OK, that would be v4 ReleaseCandidates.
I can't see it in 3.9, but perhaps other users can.

[Stem]

I was looking at the latest (free) release from vendors site. (file version 3.9.0.1008)

[Rainwalker]

I saw the same issues with free version 3.9 and i am thinking the Pro version also.

[SUPERAntiSpy]

-{ Quote: "Long after ( at least 5 minutes ) i receive the update there are still at least four ports established with SAS......this ONLY happens with SAS updates and no others ???
Uncomfortable" }-

WININet (the built-in windows library) that we use to do our Internet transfers is the one leaving those ports "open" - they are doing nothing and cannot harm your system or explose your system to any danger. Windows appear to try and "cache" the port access to they appear to be left open even after our application has properly closed the ports.

[Stem]

-{ Quote: " Windows appear to try and "cache" the port access to they appear to be left open even after our application has properly closed the ports." }-Your application is not closing the connections. I have full logs on this.

First log after manual update. The connections are closed. (duration < 1 sec)
197815


Second log after re-boot. Manual update. The top 3 connections are not closed by your application. The last packets sent are "ack" (duration 6.5 minutes)
197816

On each manual update since, the connections are not closed by the application.


I can post full packet info if required.

[SUPERAntiSpy]

-{ Quote: "Your application is not closing the connections. I have full logs on this.

First log after manual update. The connections are closed. (duration < 1 sec)
197815


Second log after re-boot. Manual update. The top 3 connections are not closed by your application. The last packets sent are "ack" (duration 6.5 minutes)
197816


I can post full packet info if required." }-

We are issuing the close to the WinInet API - for some reason it's not closing out the connections. I am not sure what can be done about this - it would have to be addressed in a version after 4.0 - the open ports are of now harm of course.

[Stem]

-{ Quote: "We are issuing the close to the WinInet API - for some reason it's not closing out the connections. I am not sure what can be done about this - it would have to be addressed in a version after 4.0 - the open ports are of now harm of course." }-I am currently having a few problems monitoring this. The only Wininit API I have seen is "wininet.h" InternetGetcookieA (http://source.winehq.org/WineAPI/InternetGetCookieA.html)

I will continue to look at this, but will leave the thread at it will go too far off topic.

But it is now clear there is a problem.

[SUPERAntiSpy]

-{ Quote: "I am currently having a few problems monitoring this. The only Wininit API I have seen is "wininet.h" InternetGetcookieA (http://source.winehq.org/WineAPI/InternetGetCookieA.html)

I will continue to look at this, but will leave the thread at it will go too far off topic.

But it is now clear there is a problem." }-

What are the specifics of your system setup - we are not seeing this on our systems here - they stay around for a few seconds then close up as they are supposed to when the session handle is closed. What firewall, etc. are you running?

[Stem]

-{ Quote: "What are the specifics of your system setup - we are not seeing this on our systems here - they stay around for a few seconds then close up as they are supposed to when the session handle is closed. What firewall, etc. are you running?" }-
I looked at 3 setups:-

1] XPsp2 all updates~ Jetico2
2] XPsp2 all updates~ LnS
3] XPsp2 base on VM~ no firewall.

With SAS free

[Rainwalker]

-{ Quote: "I am currently having a few problems monitoring this. The only Wininit API I have seen is "wininet.h" InternetGetcookieA (http://source.winehq.org/WineAPI/InternetGetCookieA.html)

I will continue to look at this, but will leave the thread at it will go too far off topic.

But it is now clear there is a problem." }-
Please hang in there Stem...i began the thread with the hope of resolving this.......and thank you for your contribution thus far.....

[SUPERAntiSpy]

-{ Quote: "Please hang in there Stem...i began the thread with the hope of resolving this.......and thank you for your contribution thus far....." }-

What application are you using to indicated the non closed ports? TCPView shows them closing and going away properly. I am not really too concerned about this as it poses no security or resource problem, but would like to check it out - it may be something we can't do anything about using WinINET.

[Stem]

-{ Quote: "What application are you using to indicated the non closed ports?" }-I have used a number of applications.

Including:
Colasoft~ (posted report) shows connections remain.
Port explorer
Openports
TCPView
Application monitor within the firewalls.

[Ocky]

I have also noticed this using Current Ports application.
However this only happens when I manually check for updates
and there are no updates available (pop-up notification in tray).
If updates are available, downloaded and installed, the ports
all close as they should. (Using version 3.9.1008 Windows XP SP2
and doing only manual updates.)

[SUPERAntiSpy]

-{ Quote: "I have also noticed this using Current Ports application.
However this only happens when I manually check for updates
and there are no updates available (pop-up notification in tray).
If updates are available, downloaded and installed, the ports
all close as they should. (Using version 3.9.1008 Windows XP SP2
and doing only manual updates.)" }-

How long do those stay open?

[Ocky]

-{ Quote: "How long do those stay open?" }-
Until I exit by r/click on the beetle icon or close the internet connection
i.e. all the time probably; I was only online for about 1 hour.

[Rainwalker]

-{ Quote: "Until I exit by r/click on the beetle icon or close the internet connection
i.e. all the time probably; I was only online for about 1 hour." }-
Yup....anything else Stem ?

[SUPERAntiSpy]

-{ Quote: "Yup....anything else Stem ?" }-

You do realize that this is of no impact to your system, does not pose any security threat, etc. correct?

[Rainwalker]

-{ Quote: "You do realize that this is of no impact to your system, does not pose any security threat, etc. correct?" }-
Ports that show themselves to be open concern me. Of the various program updates i receive, only your servers are showing this; now and in the past. Post #27 and others bring me no relief.

[SUPERAntiSpy]

-{ Quote: "Ports that show themselves to be open concern me. Of the various program updates i receive, only your servers are showing this; now and in the past. Post #27 and others bring me no relief." }-

They concern you even though a developer with over 25 years of experience in software development is telling you that they can't harm your system, pose no security threat, etc. I guess there is not much that can be done - I wish you the best in your search for a security application.

[Stem]

-{ Quote: "You do realize that this is of no impact to your system, does not pose any security threat, etc." }-The concern from the member (from first post) is the fact that the application is keeping connection. If this is a security problem would need time to be tested (as the application is on port/listening), what inbound packets can then be processed/pushed through this, will these cause that application problems or?,... yes, there are a number of questions that can arise.
There is of course the concern from users as to why such a connection remains, as this can become a question of privacy.

Please realize, at this time, I was only confirming that the connections remain, which I was actually only looking at.

I would now ask if you are putting forward confirmation of this being a confirmed problem (and a fix will be made in later versions)?
Or,
Are you saying you believe it is of no concern and it will remain?

[SUPERAntiSpy]

-{ Quote: "The concern from the member (from first post) is the fact that the application is keeping connection. If this is a security problem would need time to be tested (as the application is on port/listening), what ionbound packets can then be processed/pushed through this, will these cause that application problems or?,... yes, there are a number of questions that can arise.
There is of course the concern from users as to why such a connection remains, as this can become a question of privacy.

Please realize, at this time, I was only confirming that the connections remain, which I was actually only looking at.

I would now ask if you are putting forward confirmation of this being a confirmed problem (and a fix will be made in later versions)?
Or,
Are you saying you believe it is of no concern and it will remain?" }-

The application has closed the connection after our definition check is complete. The port appears to stay open for a period of time (it always closes in all of our tests and tests we have had other users run). If it stays open for a period of time, this is likley due to WinINet/Windows not releasing the connection - no data can be passed through it as there is nothing listening on either end.

If after further testing, this does appear to be an error, or a way to force the closure we will look into it for a future version.

[Stem]

-{ Quote: "The application has closed the connection after our definition check is complete." }-I will look more into this.

As for such as "open_ports", this does show current connection to your update server, and this does remain until your application is terminated. (other internal port checks show the same) the check is made 10 minutes after update attempt.

I will look at possible mis-information from the OS on this, and make external checks on the ports in use (for members: trying to check this with such as shieldsup will not give a correct report,.. such as (simple example) syn_ack scan is needed to check.


Just curious: As you put forward using Wininet, is the cache cleared by your app (would that not stop such a problem with the cache?)

[Stem]

Update.

I have made a number of checks on this. The ports are being kept in use, but is still unclear as to why. (hooking into SAS with API monitors causes SAS to not update)

All internal checks show SAS as keeping connections to the servers, checking this shows that the local ports are in use, on exit from SAS (from tray icon) connection resets are then sent to the SAS servers. (logs from some firewalls show these resets as being sent from the SAS application)

I have looked at a number external scans, and I have only received what I would expect from a closed/filtered port.

I do still need to find time to fully spoof packets, but would say at this time it is just a case that SAS is not closing these connections correctly.

[SUPERAntiSpy]

-{ Quote: "Update.

I have made a number of checks on this. The ports are being kept in use, but is still unclear as to why. (hooking into SAS with API monitors causes SAS to not update)

All internal checks show SAS as keeping connections to the servers, checking this shows that the local ports are in use, on exit from SAS (from tray icon) connection resets are then sent to the SAS servers. (logs from some firewalls show these resets as being sent from the SAS application)

I have looked at a number external scans, and I have only received what I would expect from a closed/filtered port.

I do still need to find time to fully spoof packets, but would say at this time it is just a case that SAS is not closing these connections correctly." }-

I traced through the code, the prots are being closed by the application. In all cases they ports will close themselves. Windows seems to be holding the connection open after we close the session.

Again, this represents no security risk, or resource issues.

[Stem]

-{ Quote: "Windows seems to be holding the connection open after we close the session." }-Issue correct commands and windows will do as instructed. Please do not blame windows for this.

[SUPERAntiSpy]

-{ Quote: "Issue correct commands and windows will do as instructed. Please do not blame windows for this." }-

We are using WinINET and are doing it properly. We have been developing software for over 25 years, we know what we are doing (obviously).

As stated before, we will look into forcing the ports to close immediately after use - but to me, focusing on removing rootkits, spyware, malware that others miss is more important.

I appreciate you brining this to my attention - but respectfully, I am not going to waste more time arguing back and forth over an issue that has no impact on the system, security or resources.

[lu_chin]

I agree with Stem here. Windows APIs are used by so many applications out there and it will seem strange that if such a bug in M$' own code indeed exists, many other applications will hold ports open too. How about a short code snippet to open and then close the same port immediately by using the same Windows APIs. Will that port close or stay open?

-{ Quote: "Issue correct commands and windows will do as instructed. Please do not blame windows for this." }-

[Stem]

-{ Quote: "We have been developing software for over 25 years, we know what we are doing (obviously)." }-I would respectfully, think of other possibilities.. If you are unable to make your software release ports, that for me is a programmer error.

[SUPERAntiSpy]

-{ Quote: "I would respectfully, think of other possibilities.. If you are unable to make your software release ports, that for me is a programmer error." }-

As stated, this is a closed issue. I have clearly stated we will look into a way to force the ports to close immediately so you won't have to watch them stay open for a few minutes even though there is no consequence to the system, product, or anything. There is no security risk, resource waste or any harm being done to any system. If you don't want to use SUPERAntiSpyware, that is your choice, I respect that - please stop trying to insult my teams development abilities.

[SUPERAntiSpy]

-{ Quote: "I agree with Stem here. Windows APIs are used by so many applications out there and it will seem strange that if such a bug in M$' own code indeed exists, many other applications will hold ports open too. How about a short code snippet to open and then close the same port immediately by using the same Windows APIs. Will that port close or stay open?" }-

For users that may not be development experts they should know that a simple code fragment will behave much differently than the same code fragment in a real, live application.

To test your "theory", you would have to replicate the software, our servers, the path that server is taking from your location to the servers, the sequence of commands, API calls, scripts being accessed, etc. that are taking place to do such an experiment, it is not as simple as "using a code fragment".

[Page42]

-{ Quote: "As stated, this is a closed issue. If you don't want to use SUPERAntiSpyware, that is your choice, I respect that - please stop trying to insult my teams development abilities." }-
I don't think that this is about whether Stem does or doesn't want to use SAS. And I haven't read anything that even slightly resembles an insult.

[Stem]

-{ Quote: "please stop trying to insult my teams development abilities." }-No insult intended. But I know from other software that uses such API, they close off connections/port used correctly.

-{ Quote: "As stated, this is a closed issue" }-Not for the thread starter.

[SUPERAntiSpy]

-{ Quote: "I don't think that this is about whether Stem does or doesn't want to use SAS. And I haven't read anything that even slightly resembles an insult." }-

We close the ports, Windows keeps the ports open after we issue the close command - Stem claims that's not the case - so I am going to leave it at that - I am going to focus on continuing to fight spyware.

[Panther]

-{ Quote: "If you don't want to use SUPERAntiSpyware, that is your choice, I respect that - please stop trying to insult my teams development abilities." }-

Security issue or not, this is a a programmer error, no more no less.


Stem never insulted you or your team. On the contrary, he has been very polite.

If this is the way your company handles well argumented critisism, you just lost a customer (possibly many more to come).

[SUPERAntiSpy]

-{ Quote: "No insult intended. But I know from other software that uses such API, they close off connections/port used correctly.

Not for the thread starter." }-

I respect your opinion and again, have stated we will look into forcing the close of the ports. You may wish to let the original poster know, as I have, that a port like that staying open for a period of time respresents no security risk, or resource drain on the system - I believe that's the (original) concern of the user.

I appreciate the data you have provided.

[SUPERAntiSpy]

-{ Quote: "Security issue or not, this is a a programmer error, no more no less.


Stem never insulted you or your team. On the contrary, he has been very polite.

If this is the way your company handles well argumented critisism, you just lost a customer (possibly many more to come)." }-

There is no proven fact here - Stem is stating one thing from an outside observation, which I respect and appreciate, and I am stating something from a developer with access to the physical code.

I am sorry that you, or others, would not use our product because I am defending my product and my position based upon the fact that I have traced through our code and the ports are being closed. Windows appears to hold them open longer after the session is closed - I have stated we will look into a way to force the closure.

You can search the forums, and see we have faced much criticism from outside sources and if we have a bug, we fix it, if something needs to be addressed we address it, if a user suggests a feature, it goes on our wish list.

I apologize to the group if I am coming accross "harsh" or "rude", but this thread is taking up lots of time that could be better spent fighting spyware and not arguing over something we have stated we will look into :)

[SUPERAntiSpy]

-{ Quote: "No insult intended. But I know from other software that uses such API, they close off connections/port used correctly.

Not for the thread starter." }-

Stem - if it's ok, I will PM you when we have code changes to force the port closure immediately (after version 4.0 releases) and you can run your tests again. I would also like to try and replicate your situation here - if you wouldn't mind PM'ing me the exact setup, tools, tests you are performing I would like to trace through and see what Windows is actually doing in that setup as in our tests here, the ports do close withing minutes of the update.

[SUPERAntiSpy]

Just for the record -> If there is an issue in our product we fix it. If this turns out to be an issue it will be addressed. At this point, it appears the code is closing the ports on our systems and other's systems we have tested. My hunch here is that Windows is, for some reason, holding the ports open after the session is closed as I have verified in the debugger the session handles are closed.

If we can reproduce the circumstances and replicate the situtation we will address it like we do everything else in our products. We address all concerns from any user.

[Jadda]

I don't have any experience with programming or whatsoever. For me, I don't know if open ports after an update with SUPERAntiSpyware's servers are dangerouse for you and you're system. But when a developer says it's not harming your system, or draging any systemresources, I feel well enough to let it be.

Panther: To leave a such great product over a little discussion (this is a forum), is to bad. SUPERAntiSpyware is a great product, and I'm sure they will not loose more customers just because of this little discussion. I rather keep a good software as SUPERAntiSpyware, than throw it away because two humanbeings are just acting like, yes, human. Just because Nick is the developer behind this software, he has the right to have his own opinion and are free to share them.

[Stem]

To set this straight from my point.

I looked at this from the point of ports in use (shown from many applications) due to posts (and PM`s made).

I have no problem with SAS, in fact many of my friends who work HJT recommend this.

I was looking at the report, which is correct, internally, the ports/connections remain. Externally, these are not shown. I see nothing that shows these ports open. (but as always, I re-check... not because it is SAS, but because it is what I do)

[Stem]

-{ Quote: " But when a developer says it's not harming your system, or draging any systemresources, I feel well enough to let it be." }-Why?

To ask is correct.
Is it not?

[Jadda]

Well, yes of course it's right to ask. Absolutly. I'm not saying not do. But when Nick now have said like 5 times, that the open ports doesn't harm your system, I feel well enough to trust him. But this is just me. I respect that other may be more careful, I really understand. I'm also cautious when it comes to this, but I trust SUPERAntiSpyware as a company well enough. Again, this is just my opinion.

But then again, I'm not to familiar with this, so I don't know what the consequence can be.

But yes, it's better to ask than leave it. I hope the problem will be solved. :)