I'd like to add a new system call via an LKM, but I'm not sure how to do this. That is, I know that if I want to add a completely new system call, I can look through the sys_call_table and find a sys_ni_syscall and just replace it, but I was curious if it was possible to actually add to the sys_call_table. I realize it's probably not possible, given that it's a fixed size array, but I was wondering if there were any other clever ways to add system calls without overriding an unused system call number.
Here's an example
linux system calls
edit:
The example above shows howto implement a system call, as far as implementing one from a loadable module; AFAIK, that's not possible, unless you where to overwrite an existing one because the size of the array is a #define.
Keep in mind there are user space changes required as well, at least if you want to be able to actually use the new system call.
Check The Linux Documentation Project website for "The Linux Kernel Module Programming Guide" (http://www.tldp.org/LDP/lkmpg/2.6/html/index.html). Specifically, look here for System Calls: http://www.tldp.org/LDP/lkmpg/2.6/html/x978.html. That should give you a start, at least.
This is an old question, but nevertheless I want to propose my solution. The easiest way to implement a "system-call-like" environment is to rely on a fake device.
In particular, you could create a new device driver which is not actually driving anything. Yet, writing on it, can cause the installed module to perform the required actions.
Additionally, if you want to offer several services, you might map them to ioctl operations.
Related
Similar to the linux execve(3) syscall, I want to replace the current process with a new one in Rust, in a way that works on both Unix and Windows systems. I'm fine with using crates if necessary, although I would like to stay away from unsafe.
So far, the only thing I've found in the standard library is std::os::unix::process::CommandExt::exec, but this only works on Unix. Looking for crates, I found the exec crate, but it doesn't appear to support Windows. However, this open PR mentions that it's possible to use the wexecvp syscall on Windows to achieve the same functionality, although it doesn't work on the Windows Runtime and only works on Win32. (That's good enough for me, though.) I'm at a dead-end on how to do this without breaking out libc::wexecvp and unsafe.
Is there a way to replace the current process with a new one in a cross-platform way in Rust?
This is a question that is independent of the programming language used, because it's about the process models of operating systems.
The answer is simply No.
The Windows process model doesn't work this way -- it's not a *nix.
Some things are fundamentally nonportable. So, you'll need to figure out what your functional requirement is (e.g. stdio handle inheritance, permissions, environment, etc.), and how to implement that on the other platform(s).
I can't get more specific because you'd need to provide more details on what "replace the current process by another one" means for your app You can always launch another program and quit, which naively sounds like the same thing :-).
There is a security issue in linux kernel, which affects most of android devices and basically allows any user to become root.
Since I am linux user for quite some time, I am very curious how this exploit works, especially how can I check whether my kernel in my PC (custom built) or on any of my servers, is vulnerable to this or not. Is there any source code (preferably documented) or details of the exploit so that I could see how it works? I could only find the generic information or closed source binaries that do exploit the bug and give you root if executed by any user, but no background information or details of which part of kernel has the flaw and how is it even possible to do this.
So far I found this interesting article http://tinyhack.com/2014/07/07/exploiting-the-futex-bug-and-uncovering-towelroot/ which explains that it uses stack hack, by calling certain syscalls in order to get something into a stack of futex_queue. While I understand how that works, I have no idea how changing anything in that stack can actually elevate privileges of current process. What I found interesting is, that this guy say that since kernel 3.13 something has changed and now different technique is needed to exploit this. Does it mean that this was not even fixed and is still exploitable in recent kernel that can be downloaded from kernel.org?
As SilverlightFox said, the Security portion of stackexchange (http://security.stackexchange.com/) probably would be better for this, but here goes nothing.
From the sound of it, this hack appears to be a way to elevate any users' terminal/kernel for a given amount of time, which is, not to say the least, bad. My idea of how this sort of issue would work is a program that overloads the futex_queue by calling those said syscalls and then provides, temporarily, the user with superuser access.
I looked around at the link you provided and found that it does require remote login from SSH or similar procedures. In a console screenshot, it uses the line gcc -o xpl xpl.c -lpthread, which shows that this exploit is done in C. And a quote directly from the article:
This is actually where the bug is: there is a case where the waiter is
still linked in the waiter list and the function returns. Please note that a kernel stack is completely separate from user stack. You can not
influence kernel stack just by calling your own function in the userspace. You can manipulate kernel stack value by doing syscall.
In the image at http://www.clevcode.org/cve-2014-3153-exploit/, it shows the output of the towelroot exploit, testing the address limits and getting into the task structure to spawn a superuser shell. Also, in the tinyhack article, it gives a simple recreation of this exploit's base, so I'd recommend taking a look at that and working from it.
I don't know any clear form of testing if your system is vulnerable, so the best I can tell you is to try and harden your systems and do all you can to keep it protected. Anyway, I don't think that someone would easily get hold of server ports and logins to run this exploit on your system.
Cheers!
I am trying to implement a spin lock using the test_and_set_bit function. I found a bitops.h file which consisted of this function. However, in my current kernel version which is 3.0, the function is not included in that header file i.e, bitops.h. Any anyone provide some references where I can find that?
Not sure if I totally understand your question, but including <linux/bitops.h> should bring in the definition of test_and_set_bit(). The actual definition of the function is not in include/linux/bitops.h but it is picked up via the include of <asm/bitops.h> that is in the linux/ version of the include.
So to see the actual definition of test_and_set_bit() you can look in arch/arm/include/asm/bitops.h or arch/x86/include/asm/bitops.h (or whatever other architecture you're interested in).
By the way, there's no reason to need to implement your own spinlock -- the kernel has (of course) the standard spinlock_t and also functions like bit_spin_lock() that use a single bit as a lock.
I am currently a student at a university studying a computing related degree and my current project is focusing on finding vulnerabilities in the Linux kernel. My aim is to both statically audit as well as 'fuzz' the kernel (targeting version 3.0) in an attempt to find a vulnerability.
My first question is 'simple' is fuzzing the Linux kernel possible? I have heard of people fuzzing plenty of protocols etc. but never much about kernel modules. I also understand that on a Linux system everything can be seen as a file and as such surely input to the kernel modules should be possible via that interface shouldn't it?
My second question is: which fuzzer would you suggest? As previously stated lots of fuzzers exist that fuzz protocols however I don't see many of these being useful when attacking a kernel module. Obviously there are frameworks such as the Peach fuzzer which allows you to 'create' your own fuzzer from the ground up and are supposedly excellent however I have tried repeatedly to install Peach to no avail and I'm finding it difficult to believe it is suitable given the difficulty I've already experienced just installing it (if anyone knows of any decent installation tutorials please let me know :P).
I would appreciate any information you are able to provide me with this problem. Given the breadth of the topic I have chosen, any idea of a direction is always greatly appreciated. Equally, I would like to ask people to refrain from telling me to start elsewhere. I do understand the size of the task at hand however I will still attempt it regardless (I'm a blue-sky thinker :P A.K.A stubborn as an Ox)
Cheers
A.Smith
I think a good starting point would be to extend Dave Jones's Linux kernel fuzzer, Trinity: http://codemonkey.org.uk/2010/12/15/system-call-fuzzing-continued/ and http://codemonkey.org.uk/2010/11/09/system-call-abuse/
Dave seems to find more bugs whenever he extends that a bit more. The basic idea is to look at the system calls you are fuzzing, and rather than passing in totally random junk, make your fuzzer choose random junk that will at least pass the basic sanity checks in the actual system call code. In other words, you use the kernel source to let your fuzzer get further into the system calls than totally random input would usually go.
"Fuzzing" the kernel is quite a broad way to describe your goals.
From a kernel point of view you can
try to fuzz the system calls
the character- and block-devices in /dev
Not sure what you want to achieve.
Fuzzing the system calls would mean checking out every Linux system call (http://linux.die.net/man/2/syscalls) and try if you can disturb regular work by odd parameter values.
Fuzzing character- or block-drivers would mean trying to send data via the /dev-interfaces in a way which would end up in odd result.
Also you have to differentiate between attempts by an unprivileged user and by root.
My suggestion is narrowing down your attempts to a subset of your proposition. It's just too damn broad.
Good luck -
Alex.
One way to fuzzing is via system call fuzzing.
Essentially the idea is to take the system call, fuzz the input over the entire range of possible values - whether it remain within the specification defined for the system call does not matter.
I need some opinions pointers on creating pseudo-filesystems for linux/*nix systems.
Firstly when I say pseudo-filesystem I mean something like /proc where the structure within does not represent actual files on disks or such but the state of the kernel. I would like to try something similar as an interface to an application.
As an example you could say, mount a ftp url to your filesystem and your browser app could then allow you to interact with the remote system doing ls et al on it and translating the standard filesystem requests into ftp ones.
So the first question is: how does one go about doing that? I have read a bit about it and it looks like you need to implement a new kernel module. If possible I would like to avoid that - my thinking being that someone may have already provided a tool for doing this sort of thing and provided the module to assist already.
My second question is: does anyone have a good list of examples of applications/services/whatever using this sort of technique to provide a filesystem based interface.
Lastly if anyone has any opinions on why this might be a good/bad idea to do such a thing on a generic level I would like to hear it.
A userspace filesystem via fuse would probably be your best way to go.
Regarding the next part of your question (which applications use this method), there is the window manager wmii, it uses the 9p filesystem via v9fs, which is a port of 9p to Linux. There are many examples on plan9, most notably acme. I suggested fuse because it seems more actively developed and mainstream in the Linux world, but plan9 is pretty much the reference for this approach as far as I know.