callr icon indicating copy to clipboard operation
callr copied to clipboard

please do not run unsigned dll files with random names from temp folder

Open christophvw opened this issue 4 months ago • 6 comments

Please do not run unsigned dll files with random names from temp folder - this is what malware does. (on Windows)

Our application whitelisting will block this: %OSDRIVE%\USERS\USERNAME\APPDATA\LOCAL\TEMP\RTMPKENVDF\CALLR-CLIENT-X64-748EB4F.DLL was blocked,

christophvw avatar Feb 19 '24 08:02 christophvw

AFAIR R CMD INSTALL does that as well by default when installing a package from source. Is that OK, and if yes, why?

gaborcsardi avatar Feb 19 '24 08:02 gaborcsardi

When you install packages with admin rights they will go into %PROGRAMFILES%\R 4.x... which is fine.

with user rights they will be installed into: %OSDRIVE%\USERS\USERNAME\APPDATA\LOCAL\R\WIN-LIBRARY

As this is not a random path in the temp folder - it can be whitelisted. Security wise it would be better to work without path whitelistings but this would require all binary files from R packages to be signed.

christophvw avatar Feb 19 '24 08:02 christophvw

Unfortunately this is not an easy fix, because Windows locks the loaded DLL file which leads to complications. Typically what happens is that users cannot update packages because some process is locking the DLL file inside the package.

Nevertheless, if loading the DLL from the temporary directory fails, then we try to load it from inside the (processx) package. Apparently this does not work for you, probably some virus protection stops the process instead of returning an error for the system call?

gaborcsardi avatar Feb 19 '24 10:02 gaborcsardi

Typically what happens is that users cannot update packages because some process is locking the DLL file inside the package.

Ah, I didn't find an explaination by reading the code.

Nevertheless, if loading the DLL from the temporary directory fails, then we try to load it from inside the (processx) package. Apparently this does not work for you, probably some virus protection stops the process instead of returning an error for the system call?

This might work but I get tons of block messages from our SIEM. (I am not the user of the package in this case)

christophvw avatar Feb 19 '24 10:02 christophvw

This might work but I get tons of block messages from our SIEM. (I am not the user of the package in this case)

Is it possible to configure your tool to avoid logging if the DLL matches some patter? E.g. **/callr-client-*?

Alternatively, we can introduce an environment variable that would avoid using the temporary files. Would that work for you?

gaborcsardi avatar Feb 19 '24 11:02 gaborcsardi

Is it possible to configure your tool to avoid logging if the DLL matches some patter? E.g. **/callr-client-*?

Yes, but then I would have too many rules, which will slow down everything and makes it hard to handle.

Alternatively, we can introduce an environment variable that would avoid using the temporary files. Would that work for you?

Yes, that would be fine. I could set it in Renviron.site when packaging R.

christophvw avatar Feb 21 '24 06:02 christophvw

Should be fixed in the next release, happening later today.

gaborcsardi avatar Mar 25 '24 10:03 gaborcsardi