SAS Open Ports

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

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?

 

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

 

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.

 

I have used a number of applications.

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

 

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?

 

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 ?

 

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.

 

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.

 

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?

 

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.

 

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

 

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.

 

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.

 

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?

 

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.

 

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