malmon wrote:
RX14 wrote:
malmon wrote:
RX14 wrote:
@[deleted], no, I said it was to stop exploits. There were known exploits in virtualbox, and they fixed them. If you're oracle, what do you do? Not fix a massive explot just so that some people can mod their windows? Seems like a terrible idea to me.
Isn't it more of a Windows issue then? And not a VirtualBox issue? Surely it's Windows' responsibility to keep the integrity of it's DLLs in check?
Yes, it's a windows issue because windows loads DLLs from too many places, many of which don't need superadmin to access. So VirtualBox requires all loaded DLLs to be signed by a certificate trusted by windows. If you really really want to use a custom DLL, just create a custom certificate and sign it yourself. This is both supposedly secure if you do it right and customisable.
So how come Linux isn't vulnrable to this?
Because the paths where .so files are stored in are owned by root, so normal users can't modify them. You can do injection by modifying LD_PRELOAD env var then running a process, but thats not particularly exploitable.
DLL/shared library injection is a method of injecting code into a process which runs at a higher permission level than you. Virtualbox is one of the processes that has needs to run as a higher-level user so it protects itself from this. On linux, you would need to set LD_PRELOAD in the environment of a process that's run as root, which would usually require an exploit in the init scripts, which doesn't happen often.
Rootkits using shared libraries is different, simply a way of hiding the virus. To inject into the shared library files, you already need to be root, which is usually obtained through another exploit of week ssh. If someone is root on your linux box, there's 1000 ways they can hide their code, including inside the kernel itself, shared library injection is simply another techique.
