OpenCL* for CPU
Ask questions and share information on Intel® SDK for OpenCL™ Applications and OpenCL™ implementations for Intel® CPU.
Announcements
This forum covers OpenCL* for CPU only. OpenCL* for GPU questions can be asked in the GPU Compute Software forum. Intel® FPGA SDK for OpenCL™ questions can be ask in the FPGA Intel® High Level Design forum.

Dangers of Running 3rd Party OpenCL

FOD
Beginner
426 Views

Hello fellow OpenCL enthusiasts!

I'm currently working on a process that will run 3rd party OpenCL sources automatically and I'm worried about security on my system. I was wondering how secure it is to run code that I didn't write myself.

Technically, we don't have access to system calls or libraries doing system calls for us (right?). We don't have access to the hard drive, the network, etc. Say there was a malicious programmer that made the code. Would there be a way for him to trick the compiler into doing anything other than input/computation/output? Is there a way to write assembler code or trick the system to run binary directly? Is there any way to test this, any expert I could consult about this? Is GPU safe and CPU potentially unsafe?

I'd really like an answer this question before continuing with my project.

Thanks for your help,

FOD

0 Kudos
1 Solution
Doron_S_Intel
Employee
426 Views

Hello FOD,

If security is a concern we would strongly advise against running nebulous OpenCL code. To give a more in-depth assessment we'd need to understand what assets you're trying to protect, however broadly speaking there's no way to prevent user-supplied code from throwing an exception (for instance) and using that to execute arbitrary code with the application's privileges.

There are other potential risks: kernel code corrupting the stack to execute arbitrary code when returning from a kernel function, identifying the address range of the C run-time library in the process address space and jumping to a point there, and more.

Hopefully that's enough to persuade you that's not a safe thing to do, from a security standpoint.
If you can elaborate on the use case, we may be able to give a more accurate assessment or suggest an alternative.

Good luck,
Doron

 

View solution in original post

0 Kudos
2 Replies
Doron_S_Intel
Employee
427 Views

Hello FOD,

If security is a concern we would strongly advise against running nebulous OpenCL code. To give a more in-depth assessment we'd need to understand what assets you're trying to protect, however broadly speaking there's no way to prevent user-supplied code from throwing an exception (for instance) and using that to execute arbitrary code with the application's privileges.

There are other potential risks: kernel code corrupting the stack to execute arbitrary code when returning from a kernel function, identifying the address range of the C run-time library in the process address space and jumping to a point there, and more.

Hopefully that's enough to persuade you that's not a safe thing to do, from a security standpoint.
If you can elaborate on the use case, we may be able to give a more accurate assessment or suggest an alternative.

Good luck,
Doron

 

0 Kudos
FOD
Beginner
426 Views

Hi Doron,

Thanks a lot for your answer, it's really appreciated. My project is some sort of BOINC like network which would run OpenCL code from clients. I was hoping the abstraction level would provide enough security, I'm grateful you informed me of potential problems. I will have to find a way either to block privileges of the program running my OpenCL code (Running with user privilege, DropMyRights?), emulate the processor if I can't find a way to run in a secure enough environment >.<, or automatically scan the code to find malicious section, but that is probably quite impossible...

You probably saved me from weeks of headaches :)

FOD

0 Kudos
Reply