Odd connection request from eraser?

Charon

Charon

New Member
I've been using Eraser for quite a while but I don't recall, in all that time, seeing the application making a request to connect to the Internet, that is until the last day or so.

I'm currently running 6.0.8.2273, which has been installed for the last month or so; Yesterday, when deleting a file, Eraser requested (via my firewall) an Internet connection, first to DNS and then to 213.222.201.178 (Unizeto Technologies S.A.) some kind of systems integration outfit, specialising in PKI, based in Poland. Now, every time I attempt to delete anything, I get the same prompt.

I couldn't find a setting within Eraser for enabling/disabling automatic updates and as I said, I've never seen this before from Eraser. For now the connections are blocked but this seems to be having an impact on Eraser, as it now 'hangs' when attempting to erase, I assume until the connection request times out, before completing the task.

Is this normal behaviour?

Thanks.
 
The only unprompted Internet connection that Eraser initiates is the initial validation of the Root Certificates on first install. If this is unsuccessful, it will be retried when Eraser is next used.

The validation is not done by Eraser itself, but by the relevant Windows function, which can be confusing as it identifies the request as coming from Eraser. Unless you have the kind of firewall intervention you mentioned, the process is transparent to the user. As far as I know, it is the Windows function which decides where it wishes to connect. From my researches, Unizeto appears to be associated with the Certum certificates which I know Eraser uses.

It has to be recognised that there are mixed feelings about the issue of transparent validation. The root certificates are used to ensure that rogue plugins are not installed with Eraser (which is something we all want), but people are understandably chary these days about any application that 'dials home' without asking permission. Perhaps some sort of dialog that explains the situation (such as the one associated with uploading Crash Reports from the Black Box plugin incorporated into beta builds) might help.

David
 
Unfortunately the validation occurs very early in the validation process before any UI appears, so I don't think there's a straightforward way of implementing this. In addition, when plugins are installed to the non-interactive service (for future versions, I'm thinking ahead) what will happen? There will be no user to confirm what to do with the request.

Having said this, it is possible to disable certificate validation and thus prevent the connection to the Certum servers. However, in the event that a certificate has been compromised, no protection will be offered and the (rogue?) plugin will be loaded without question.
 
Thank you both for your replies.

@David.

As far as I know, it's usually svchose.exe takes responsibility for maintaining the certificate database, which I assume is what you are referring to? I have a rule for svchost.exe in my firewall that allows outbound to Verisign for this purpose (Verisign being the only CA that has ever prompted a request on my system). With regard to the Eraser request, it is actually Eraser.exe (see attached) that is making the requests.

According to revouninstaller, Eraser was installed on my system on 13.11.2010, which would have been around the time I last re-imaged and yet this is the first time I have seen a request (my firewall rules are very tight, everything that doesn't have an explicit rule is blocked, especially svchost, which is only allowed to connect to a small range of IPs) From what you have said, it sounds like the connection request is legitimate, but why now? As I said earlier, these requests are coming thick and fast. Basically, every time I erase a file, there are multiple requests, which causes eraser to temporarily 'hang'.

Would I simple be better off removing and reinstalling Eraser, I was thinking about trying the 6.1 beta anyway...
 

Attachments

  • 2010-12-12_000918.png
    2010-12-12_000918.png
    13.5 KB · Views: 2,397
Charon said:
As far as I know, it's usually svchose.exe takes responsibility for maintaining the certificate database, which I assume is what you are referring to? I have a rule for svchost.exe in my firewall that allows outbound to Verisign for this purpose (Verisign being the only CA that has ever prompted a request on my system). With regard to the Eraser request, it is actually Eraser.exe (see attached) that is making the requests.
Click to expand...
svchost is just an arbitrary "host" for other code to run in. What Eraser is doing here is probably what svchost did for Verisign, checking for revocations (the Certificate Revocation List.) How Eraser does the verification is that it loads a system DLL, and calls a function in that DLL to verify the certificate, which is likely what the DLL loaded in svchost did. However, as svchost is a system EXE, the request looks like it originates from the system.

Charon said:
According to revouninstaller, Eraser was installed on my system on 13.11.2010, which would have been around the time I last re-imaged and yet this is the first time I have seen a request (my firewall rules are very tight, everything that doesn't have an explicit rule is blocked, especially svchost, which is only allowed to connect to a small range of IPs) From what you have said, it sounds like the connection request is legitimate, but why now? As I said earlier, these requests are coming thick and fast. Basically, every time I erase a file, there are multiple requests, which causes eraser to temporarily 'hang'.
Click to expand...
The certificates are checked every time Eraser loads a plugin. In this case, any erase would result in the plugins being loaded and the certificate checked again.

Charon said:
Would I simple be better off removing and reinstalling Eraser, I was thinking about trying the 6.1 beta anyway...
Click to expand...
6.1 still uses the same plugin code as 6.0. Although a new plugin design which is based on what 6.0 uses with improvements (this probably being one of them -- it adds time to the startup) will be included in future, currently the code's exactly as 6.0.
 
Thanks for the reply, Joel :)

In the interest of curiosity, I decided to let Eraser make the connection. Following this, I removed the rule from my firewall and erased another test file. It seems that following the CRL check, it appears it has no need to perform the task again, at least at this time, as I was not prompted for a connection request.

The certificates are checked every time Eraser loads a plugin. In this case, any erase would result in the plugins being loaded and the certificate checked again.
Click to expand...

So, having allowed Eraser to check the status of the certificate, may I assume the reason I'm not seeing additional requests, is simply because the certificate status was found to be in order? If so, may I also assume the process will re-occur at some later date?

Thanks again for the help :)
 
Spot on. CRLs have a fixed lifespan, which after it is expired will need to be checked again.
 
What effects does blocking this request have on Eraser? My work computer uses an internet proxy (port 80) to reach out to the internet. I've noticed that if I do not use the proxy within my wort network, which essentially blocks the outbound connection. (i.e. I forget to set iexplorer back to use the proxy server), then Eraser starts with *no erasure methods*. You can't set any eraser methods in the settings tab in the pull down list. Also, any startup tasks, like erasing the recycle bin, will cause eraser to crash when this condition exists (unreachable port 80). I have to be aware of my proxy setting when I shut the computer down so that it starts with no errors on restart. Why does Eraser need the CRL to verify the eraser methods? Is there a way to code around this if the CRL check fails?

Thanks!
 
This is really erring on the side of caution.

As explained earlier, Eraser uses the CRLs to verify that a given certificate signature is valid at the time of signing, and also valid at the point of use. Signing the plugin allows Eraser to determine that the plugin author is trusted and that the plugin can be loaded. However, should there be incidents (like last year's DigiNotar) where certificates have been found to be compromised, then disabling CRLs would mean that certain certificates would still be used even when they are no longer credible. CRLs tell the computer that the time is up and that the certificate should no longer be trusted.

I agree that Eraser can handle such conditions better. Please open a ticket on Trac to report the bad behaviour when that condition happens (if I understand you correctly, it mainly happens when you right-click a file/folder in Explorer and erase something) detailing the steps you need to trigger the crash. I'll try to fix it in 6.0.10. As a temporary workaround, however, you can go to the settings page, scroll right to the bottom, tick the Eraser.DefaultPlugins plugin and select Save Settings. Restart Eraser and the erasure methods should be there.

Sorry for the inconvenience... I think for a piece of security software paranoia is better than vulnerability.
 
You must log in or register to reply here.
Back
Top