Why not just write a FUSE module?
1. A kernel module is more 1337 ;)
2. Using FUSE you would have to guaranty that your fs overlaps all other mounted filesystems.
Kernel module for advanced rickrolling replaces open() call
11–20 of 67 posts
Re: Kernel module for advanced rickrolling replaces open() call
#12p = (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.
Re: Kernel module for advanced rickrolling replaces open() call
#13This 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.
Do read http://news.ycombinator.com/item?id=2973012 (various security issues), though.
Re: Kernel module for advanced rickrolling replaces open() call
#14Earlier quoted context omitted.
You're inserting a dodgy bit of a code into a live running kernel. You are an attacker! I mean, valid technicality, but really? If you've got the ability to insert any module you want, you have the ability (ok, not always, but usually) to rm -rf /
Bullshit. Anyone who's using open() can kill the kernel after loading this module.
Anyone who can load a kernel module can do _whatever they want_. That was my point, which you've obviously missed.
Re: Kernel module for advanced rickrolling replaces open() call
#15Earlier quoted context omitted.
Bullshit. Anyone who's using open() can kill the kernel after loading this module.
Anyone who can load a kernel module can do _whatever they want_. That was my point, which you've obviously missed.
And you are obviously missing that modern operating systems have more than just one user. :-)
Re: Kernel module for advanced rickrolling replaces open() call
#16This 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.
Do read http://news.ycombinator.com/item?id=2973012 (various security issues), though.
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.
Re: Kernel module for advanced rickrolling replaces open() call
#17Earlier quoted context omitted.
You're inserting a dodgy bit of a code into a live running kernel. You are an attacker! I mean, valid technicality, but really? If you've got the ability to insert any module you want, you have the ability (ok, not always, but usually) to rm -rf /
Bullshit. Anyone who's using open() can kill the kernel after loading this module.
I guess you meant, ``Anyone who's using open() can kill the kernel after somebody else loads the module.''. Which is far worse: any unprivileged user, say the victim of rickroll, can bite back hard.
Re: Kernel module for advanced rickrolling replaces open() call
#18Earlier quoted context omitted.
Anyone who can load a kernel module can do _whatever they want_. That was my point, which you've obviously missed.
And you are obviously missing that modern operating systems have more than just one user. :-)
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 required. That's only from the /lib/modules path and you need to be root have to inserted a module in there anyway.
And if you have that ability, worrying about the security of a module such as this seems, to me, totally and utterly pointless, because you could be inserting a rootkit, or a module that randomly deletes a file every time you press the letter A etc.
So could you explain what you mean please? Why be concerned about security when security is already compromised? How does it being multi-user make a difference?
Re: Kernel module for advanced rickrolling replaces open() call
#19Earlier quoted context omitted.
Do read http://news.ycombinator.com/item?id=2973012 (various security issues), though.
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.
Re: Kernel module for advanced rickrolling replaces open() call
#20Earlier quoted context omitted.
And you are obviously missing that modern operating systems have more than just one user. :-)
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.