Opencomputers: File permissions on the native Lua library are too broad

Created on 10 Jun 2019  Â·  4Comments  Â·  Source: MightyPirates/OpenComputers

The native lua library downloads and installs with dangerously broad world read write and execute permissions. It exposes the running user to compromising:

ls -l OpenComputersMod*
-rwxrwxrwx 1 lea lea 851843 juin   9 23:54 OpenComputersMod-1.7.4.153-lua53-native.64.so

The permissions should be octal 0750
User: read, write, execute
Group: read, execute
Others: nothing

So this instead:

chmod 0750 OpenComputersMod-1.7.4.153-lua53-native.64.so
ls -l OpenComputersMod*
-rwxr-x--- 1 lea lea 851843 juin   9 23:54 OpenComputersMod-1.7.4.153-lua53-native.64.so

Most helpful comment

I see no additional risk by leaving this file in rwx mode. If the mc server folder itself is accessible, then an exploit is already wide open.

If you are running on a multi-user system, and other users are untrusted (AND they have access to your personal files, such as mc server files), then you have other problems already and any exploits they could execute are possible with or without this change. This file's permissions add no additional vulnerability.

All 4 comments

I see no additional risk by leaving this file in rwx mode. If the mc server folder itself is accessible, then an exploit is already wide open.

If you are running on a multi-user system, and other users are untrusted (AND they have access to your personal files, such as mc server files), then you have other problems already and any exploits they could execute are possible with or without this change. This file's permissions add no additional vulnerability.

Sure, a native binary executable payload is downloaded from the wild internet and it has world write and execute permission... What could go wrong ?!

I mean, you're already downloading it from the Internet... 

a few things to consider

  1. the native isn't downloaded from the wild (at least, not currently. this can change later). it is packaged inside of our jar. we extract it when the mod is loaded
  2. we are currently (again, we may change this later) verifying the file is a byte-perfect match of the file we are storing internally.
  3. we delete the file "on exit" (again, a detail we may change in future, and we don't guarantee this as as feature). if you see the file persist after the server has been stopped, that means your jvm was aborted abnormally
    edit
  4. we also intentionally set the permissions to global read in case options 1-3 are later modified such that the file persists, and another user on the system wants to reuse the native lib
Was this page helpful?
0 / 5 - 0 ratings