
Kernel module for advanced rickrolling replaces open() call - wink
https://github.com/fpletz/kernelroll
======
exDM69
SECURITY WARNING: do not use this module! Scroll down for more information in
the discussion. This module disables a major part of kernel memory protection
and trusts user provided file names to be valid. This makes it possible for an
UNPRIVILEGED USER to do bad things.

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)

~~~
fpletz
I never had security in mind when developing this. I just did it for fun and
to prove it was possible after I had the idea. It was never intended to go
that popular.

I will incorporate all fixes and address all issues raised in the next few
days.

~~~
exDM69
You should never ever admit that you didn't think of security when writing
code, especially in the kernel space :)

I think that instead of the strlen pull request you accepted, you should use
getname/strncpy_from_user like the open() syscall does instead of
strlen+memcpy.

Also, while you're here, could you explain what is the purpose of disabling
memory write protection? Is it to allow writing to the syscall table? You seem
to enable writing in the page table for the syscall table before writing, but
never disable it. Could it be that you forgot to flush the translation
lookaside buffer (TLB) after updating the pagetable and the change you did
does not take effect soon enough? I don't know how you flush TLB's in Linux
but the Intel manuals tell you to do so after updating the page table.

It's fun to see that there were so many people interested in this, although
it's not much more than a joke. I guess part of the interest stems from the
fact that it's a small kernel module with so little code that it's easy to
grok.

~~~
Pewpewarrows
> You should never ever admit that you didn't think of security when writing
> code

For a joke weekend project that you never intended anyone to see / use
seriously? Sorry, no. I would never waste time making something secure that I
did for funzies that I'll likely never touch again. If I happen to come across
or realize a security issue as I'm writing it I _might_ make a comment there
in the source or in the README. Otherwise, that's time spent I could have been
making my real projects better and more secure.

~~~
exDM69
Did you notice the smiley at the end of that line? I intended that to mean
that I'm not really serious.

------
p4bl0
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.

~~~
seclorum
What are you talking about? The linux sources are full of simple examples of
working kernel modules.

~~~
jrockway
But those are all things like parallel port drivers. _This_ is for an Internet
meme!!!!

------
KonradKlause
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...

~~~
KonradKlause
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.

~~~
adobriyan
If we could take CR0 et al manipulations away from module authors, we'd do it
long ago. Sigh...

~~~
jrockway
This is why I avoid out-of-tree modules. At least someone had to glance over
the in-tree module before I run it on my machine. When you download random
kernel modules from the Internet, they're probably from people too lazy to
have their code properly reviewed. And if they're too lazy to have their code
reviewed, they probably don't feel too bad about disabling all page write
protection, either.

------
jconnop
I'll be saving this for April 1, 2012 :)

------
dlikhten
See, I'd do this sort of thing for any image by opening up my wifi and waiting
for people to connect. Then just ensure I serve rickroll pics/videos/flash
videos/sound whenever appropriate content is requested.

------
DrCatbox
Why not just write a FUSE module?

~~~
marbu
Maybe because the author prefers to play with kernel. Other option is create a
wrapper library and enforce it's usage with LD_PRELOAD.

~~~
KonradKlause
Using LD_PRELOAD you cannot hook a syscall like open().

~~~
waitwhat
Doesn't pretty much everything call into libc to open() things rather than
invoke the syscall directly?

~~~
exDM69
No. Assembly code invokes kernel syscalls by invoking an interrupt or using a
syscall opcode. No libc or function calls involved, so LD_PRELOAD can't hook
in.

You might even have several libc's in your system. You might have a uClibc +
Busybox based initrd and a full glibc based root system.

Btw. how does LD_PRELOAD act together static binaries?

~~~
waitwhat
I know apps _can_ invoke kernel syscalls directly, and I'm sure you could name
a handful of apps that do this all time. But are you really doing that in your
mp3 player?

------
dmk
may I suggest the use of a random rick-roll probability?

------
vedantk
Brilliant.

