21–30 of 67 posts
This is great, for the fun of course, but also and mainly because it is a simple example of a working kernel module, which is not something one can see very often.
p = (char *)(path + strlen(path) - 4); This is a very bad idea as path is user-supplied and has to be treated as malicious. An attacker can omit the string-terminator...
p = (char *)(path + strlen(path) - 4); This is a very bad idea as path is user-supplied and has to be treated as malicious. An attacker can omit the string-terminator...
BTW: write_cr0(read_cr0() | 0x10000) is a absolute no-go. It's a nice and funny kernel module but it dooms the kernel's security.
What this means is that the kernel can no longer see if a user is writing to a read-only location, which is a major part of memory protection. It has major security implications. I don't know whether other parts of the kernel enable or disable this at context switches or at other times.
What this also means is that this kernel module will only work on x86 CPU's. So no rickrolling you ARM boxes or smartphones.
Earlier quoted context omitted.
I'm genuinely interested - what do you mean? It's my understanding (and please, correct me if I'm wrong) that if you're able to insmod a non-standard kernel module into a linux system, you are root already. I don't understand what this has to do with unix being multi-user, only root has the ability to insmod /tmp/haha.ko Please note I'm not talking about the ability of the kernel to automatically load modules as requ…
Sure. Suppose your admin is a funny guy and loads this kernel module at April 1st. I (Jonny non-root user) can no longer listen to my favorite mp3, because the kernel module changes the path all the time. The admin loughs and has fun. But then later I call open() with some fancy arguments and take over the whole machine (or at least crash it). This is the part where I lough.
p = (char *)(path + strlen(path) - 4); This is a very bad idea as path is user-supplied and has to be treated as malicious. An attacker can omit the string-terminator...
[deleted]
p = (char *)(path + strlen(path) - 4); This is a very bad idea as path is user-supplied and has to be treated as malicious. An attacker can omit the string-terminator...
So your assumption on omitting the null terminator is wrong, BUT there's another flaw in this. The length of the string can be less than four bytes. By allocating the string in a nice page boundary this can be used to cause a memory protection fault.
Earlier quoted context omitted.
Yep yep I saw that too. But this kind of security issue is not specific to kernel module, it's something every C programmer should be aware of already. (I don't think it's that important here tho, because if the kernel crashes because of this module it's "lol" too :-p). What's interesting here is the C file structure (the #includes and the MODULE_* and module_* macros and functions) and the Makefile.
Manipulating the cr0 register is _very_ kernel specific.
These problems are, of course, fixable someone may fix it.
Bonus points for whoever fixes the problems and submits a pull request. All the info you need is in this discussion thread.
(edit: I can already see some pull requests on this)
p = (char *)(path + strlen(path) - 4); This is a very bad idea as path is user-supplied and has to be treated as malicious. An attacker can omit the string-terminator...
Out of curiosity, I checked out how the open syscall in linux works (see fs/open.c). It uses getname (from fs/namei.h), which effectively copies the filename from userland memory to a chunk of kernel memory. It uses strncpy_from_user to do this and uses PATH_MAX as the maximum length. So even the linux kernel does rely on the fact that there is a null terminator in the string. So your assumption on omitting the null…
But the kernel does not call strlen() on the user-supplied string...