What are the chances of my computer being hacked

[mccomase]

Hey everybody I heard when you open and forward ports on your router it makes it easier for hackers to get on your computer and get your information. Can anybody tell me if this is true or false?

[lightonflux]

If you forward a port to the internet. And a service listens to that port, then a knowledgable person can use it to gain access to the service (people who play on your server). A even more knowledgable person could use a vulnerability in the service to gain control of the service or even the account it is running under.

But that is true for all services that are publicly accessible.

On a side note, i wouldn't even bother with Minetest Servers on Home Servers, as they come and go pretty quickly. And only very few people use Minetest and fewer host Minetest. Personally i would try to gain access to your Router, which is 24/7 publicly accessible from the Internet. And many Routers have bad Security flaws. Some may even expose a service that was never meant to be accessible from the Internet and don't even has authentication. And then you use the router to redirect your facebook, mail etc. web request and get your user and password. And then work from there.


Things you can do to increase the effort of the attacker is to add some layers that shield you and your data from your personal data.

* Run minetestserver with another user that has no access to your data and has only limited rights
* Use another computer just for minetest (or even a VM if your host has enough power)
* Configure your firewall so that the computer can only talk to the router but not the other computer in your home
* other things that are too complicated for the limited threat model

[mccomase]

Thank you lightonflux for the reply

[Hybrid Dog]

Once it was possible to simulate executing every chatcommand with the commando blocks of the mesecons mod as any player. So everyone who had a command block, something to make a mesecons signal, e.g. a button, and knew the name of an admin was able to grant him-/her-/itself every privilege he wanted to, e.g. server privilege.
And there were possibilities to get access to the server pc, e.g. with the /lua chatcommand (using io.popen() or os.execute()) or the terminal mod.
l joined such a server with commandblock and terminal node. Of course l wondered, if that's really true, and wanted to find it out. l was able to run commands on the terminal node and found out that the server didn't use linux.

[prestidigitator]

...there were possibilities to get access to the server pc, e.g. with the /lua chatcommand (using io.popen() or os.execute()) or the terminal mod.

Yeah. That would be why LuaCmd says:

Any player executing this command must have the new "lua" permission, as it is about the most dangerous thing you could allow a player to do. Also not recommended for public servers. Use at your own risk!

It might also be a good reason to try this security mod, though I guess the next version of Minetest might have some similar kind of built-in sandboxing. I actually do a bunch of grepping and code inspection on every Minetest mod I use, even when just running a private game. I make sure every call to io.open() is done in a context where I'm sure it is accessing something in a mod/world directory, there are ZERO uses of dofile()/load...() where I'm not sure exactly what the argument is, os.execute() and package.loadlib() aren't used at all, etc. Even then I'm wary of installing large mods, as it's possible to slip things into code that are difficult to find. For example:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

local pkgName = "o".."s";
local funcName = "ex".."ec".."ute";
local func = _G[pkgName][funcName];
func(...);


so for me some kind of sandboxing is a very nice idea.

[Hybrid Dog]

you could also enable mod security
https://github.com/minetest/minetest/co ... 3f3e2f427d

[prestidigitator]

you could also enable mod security
https://github.com/minetest/minetest/co ... 3f3e2f427d

Right. That's why I mentioned that, "the next version of Minetest might have some similar kind of built-in sandboxing." I'm running 0.4.12, and will review the security additions when switching to 0.4.13 to see if they are adequate. I have a pretty high standard when security claims are made.

[prestidigitator]

Yeah, see it appears they left a LOT of holes in that mod security feature. I wouldn't trust it. For example, they allow you to get the environment table of standard library functions and they leave access to most of the debug library. I don't think I'd consider Minetest any more secure with it than without it.

[rubenwardy]

I wouldn't trust your Lua version.

The debug library's mostly fine, they disabled the ability to get local variables etc. What do you mean by the environment table of Lua functions? _G?

Also, did you make sure you enabled mod security? It's currently disabled by default until 0.5 due to compatibility worries.

The point of mod security is to protect the computer from a malicious mod, not protecting other mods (they need to be able to be otherridden) or the Minetest world. (Deleting blocks etc could be intended, backups should be made anyway.)

[prestidigitator]

I wouldn't trust your Lua version.

I wouldn't trust it much without a few good pairs of eyes looking it over and pounding it for holes, but it should be as good as the C++ version in general (except that it doesn't have engine support and may not be loaded first). I did cover more of the possibly unsafe API functions, and also created a pretty paranoid virtual filesystem so it should truly be impossible to access anything outside the mod and world directories. This also included sandboxing any and all functions that take a file path argument, and whitelisting the minetest API itself.

The debug library's mostly fine, they disabled the ability to get local variables etc. What do you mean by the environment table of Lua functions? _G?

It's possible for the standard API functions to have an environment table, just like you can use setfenv() to set an environment for a Lua function. If no environment table is set, it'll return the global environment (which has indeed been replaced...), but nothing in the Lua spec. guarantees that the standard API functions have no environment table set (whether one implementation of Lua does or not is irrelevant, as changing this would be API compatible and could happen as a minor release or OS-specific change). Therefore, it is a hole that could possibly allow mods to get hold of the original global environment and call any of the original API functions. This is why in the Lua security mod I very carefully only allow getfenv() and getmetatable() to return tables that have previously been explicitly set in the sandbox environment by setfenv() or setmetatable(), respectfully. No way to get hold of a function-containing table installed from outside the sandbox (yes, read-only access is indeed quite dangerous).

It's similar situations that make the debug library absolutely not safe in general. It's best to remove access to the entire debug library if possible. It's very difficult to sandbox debug functionality completely. For example, there are standard API functions (e.g. pcall() and xpcall()) that make callbacks to user-defined functions. That and debug.setlocal() could be used to change some local variable in the standard API function (if some release of Lua happened to implement them in such a way that they had local variables). Can you think of any security holes that might create? debug.setlocal() is one of the whitelisted functions in that security code, by the way.

Also, did you make sure you enabled mod security? It's currently disabled by default until 0.5 due to compatibility worries.

I'm simply inspecting the code at this point. I'm still running 0.4.12.

The point of mod security is to protect the computer from a malicious mod, not protecting other mods (they need to be able to be otherridden) or the Minetest world. (Deleting blocks etc could be intended, backups should be made anyway.)

Certainly. Well understood.

I've worked in computer security. You have to be very paranoid. When in doubt, disallow an operation. Whitelist rather than blacklist. Think of situations where read-only access is as dangerous as write access. Like I said, my standards are very high when something claims to provide security. There's a reason for that; good security is supposed to allow you to do things that would otherwise be risky. Such as running mods where you haven't inspected every line of code, even though they might try to format your harddrive.

[est31]

Wrong rubenwardy, mods do also need protection from each other, because some mods can have elevated privileges, and some only have normal ones.

prestidigitator, we want to have client side scripting one day. For that minetest needs even better lua sandboxing. The functions of the debug interface have been exposed in order to give certain functionality, like with the mesecons luacontrollers, where you not just want to have a pcall environment, but you also want to abort after a certain time, if lua code runs too long. So if access to the debug interface should be removed, we still need similar functionality. It would be really great if you could assemble a pull request that does this additional layer.

[rubenwardy]

Wrong rubenwardy, mods do also need protection from each other, because some mods can have elevated privileges, and some only have normal ones.

Not wrong. Yes, some mods may store an insecure environment in a local variable, and other mods shouldn't be able to access it. That's not about protecting the mod, it's about protecting the insecure environment. The point i was trying to convey is that the major purpose is to protect the computer. You don't want other mods to access local variables/functions because of this. (They could spam call some io function, or whatever)

With client side modding you'll want to also protect the users passwords and private info, but I doubt the former would ever be made available anyway.