I've heard that if we append some bytes at the end of an EXE file, it can still work properly. Is it true in all case? And is it a safe way?
I intend to write the demo using data in the program execution file, so it can be safe (at least to normal user) and I don't have to store data anywhere else.
This is impossible to answer with a certain Yes or No.
I assume you will store data at the end of your executable in lieu of storing program state in a configuration file. I further assume you're doing this for fun and the end result does not need to be perfect.
Any code signing mechanism that might be in place on your platform will cry foul with these sorts of tricks. The signatures will only be valid if the executable does not materially change. (At least, in the code signing mechanism I helped implement, the cryptographic signature was computed over the entire contents of the executable -- with the exception of the signature itself -- not just segments marked as executable or data in the program headers.)
Any anti-virus mechanisms that might be in place on your platform will cry foul with these sorts of tricks. Self-modifying code is definitely associated with programs attempting to remain hidden or obscure, and code that writes to itself is going to trigger alarms in behavioral anti-virus tools.
Tools such as tripwire or mtree will always complain about your program. rpm -qa or debsums will always report problems with your executable. It will be difficult to reliably transfer this program from site to site.
The permissions on standard executables in most environments would outright forbid this behavior. User accounts do not have privileges to modify most executables on the system -- only executables owned by the user that will run the executable could be written as well. (And even then, a mandatory access control system such as AppArmor, SELinux, TOMOYO, or SMACK could forbid a process from writing to the program file, if properly configured. And almost every reasonable security profile would forbid it.)
No system administrator would let two users execute and write to the executable.
You also have the pragmatic problem of finding the executable file in the first place. At least Linux provides /proc/self/exe, but (a) system administrators may not have it mounted (b) system administrators may not let most processes use it (c) if the executable file is replaced while the program is executing finding the correct file to modify may be difficult.
You have to decide between two methods of updating the executable: either you modify the existing file (ftell(3) and fseek(3)) or you write the changed contents to a new file and replace the executable. Both approaches are troublesome: if you modify the file, you might have several copies executing simultaneously, trying to write conflicting edits to the file. Clever programming can avoid huge problems, but the entire executable might not be in a consistent state. If you replace the file, you might have several copies executing simultaneously, and the disk copies of the executable might not be freed and actually removable until the system is rebooted. You could have a dozen copies of your executable program file invisibly taking up disk space. None of them could share memory while executing, increasing memory pressure.
Yes, it's possible to keep configuration data in the program executable, and even make it work in some environments. But it isn't production-quality.
Related
The problem is to prohibit access to some files (files from my "blacklist"). It implies that nobody besides me (my own kernel module) can either read or modify these files.
I've already asked this question here, on StackOverflow, but I haven't gotten an answer. There was only one solution offered to change file's permissions and file's owner. However, it isn't enough for my goals, since file's permissions as well as file's owner can be easily modified by someone else.
But I haven't given up, I've carried on studying this problem.
I replaced some fields of the system calls table by the pointers to my own functions. Thus I managed to prohibit any USER module to get an access to the files from my blacklist; in addition, this approach doesn't depend on file's permissions or file's owner. However, the key word is "user modules". I mean that any kernel module still can easily get an access to the files from my blacklist via calling, for instance, the filp_open() function. I looked through the Linux code sources and it turned out that all these system calls that I hooked (open, openat, ...) are simple wrappers and no more.
Could you help me? Is there a way to do something with filp_open that is similar to what I've done with system calls? Any other solutions (without hooking) are welcome.
What you are asking for is impossible. Theoretically, this could be achieved by running the kernel under a custom-made hypervisor or running on custom-made hardware, but it would be extremely complicated (if not impossible) to achieve in reality.
You cannot protect the kernel from itself. In any normal scenario (i.e. no dedicated hardware or hypervisor), the Linux kernel runs at the highest privilege level on the machine, and can therefore revert any changes you make if it wants. If your module needs to deny access to some file to the whole kernel, then there's really something conceptually wrong about what you are doing. Moreover, you seem to be assuming that other kernel modules would be somehow "interested" in messing with your module: why would that be the case?
Furthermore, even changing permissions or overriding syscalls does not solve any problem: unless you correctly configure kernel lockdown (kernel >= v5.4) and/or some other security measure like module signing (and ideally also secure boot), the root user is always able to insert modules and subvert your "security" measures.
If you need to deprive root of access to these files, then as I said there's really something logically wrong. The root user can already do whatever it wants with whichever configuration file it wants, of course destroying important configuration files is going to break the system, but that's not really something that you can avoid. Assuming that root is evil doesn't make much sense as a threat model in any normal scenario.
I want to write software that will detect all used/created/modified/deleted files during the execution of a process (and its child processes). The process has not yet run - the user provides a command line which will later be subprocessed via bash, so we can do things before and after execution, and control the environment the command is run in.
I have thought of four methods so far that could be useful:
Parse the command line to identify files and directories mentioned. Assume all files explicitly mentioned are used. Check directories before/after for created/deleted files. MD5 existing files before/after to see any are modified. This works on all operating systems and environments, but obviously has serious limitations (doesnt work when command is "./script.sh")
Run the process via another process like strace (dtruss for OSX, and there are equivalent windows programs), which listens for system calls. Parse output file to find files used/modified/deleted/created. Pros that its more sensitive than MD5 method and can deal with script.sh. Cons that its very OS specific (dtruss requires root privileges even if the process being run does not - outputs of tools all different). Could also create huge log files if there are a lot of read/write operations, and will certainly slow things down.
Integrate something similar to the above into the kernel. Obviously still OS specific, but at least now we are calling the shots, creating common output format for all OS's. Wouldn't create huge log files, and could even stop hooking syscalls to, say, read() after process has requested the first read() to the file. I think this is what the tool inotify is doing, but im not familiar with it at all, nor kernel programming!
Run the process using the LD_PRELOAD trick (called DYLD_INSERT_LIBRARIES on OSX, not sure if it exists in Windows) which basically overwrites any call to open() by the process with our own version of open() which logs what we're opening. Same for write, read, etc. It's very simple to do, and very performant since you're essentially teaching the process to log itself. The downside is that it only works for dynamically-linked process, and i have no idea of the prevalence of dynamic/statically linked programs. I dont even know if it is possible before execution to tell if a process is dynamically or statically linked (with the intention of using this method by default, but falling back to a less-performant method if its not possible).
I need help choosing the optimal path to go down. I have already implemented the first method because it was simple and gave me a way to work on the logging backend (http://ac.gt/log) but really i need to upgrade to one of the other methods. Your advice would be invaluable :)
Take a look to the source code of "strace" (and its -f to trace children). It does basically what you are trying to do. It captures all the system calls of the process (or its childs) so you can grep for operations like "open", etc.
The following link provides some examples of implementing your own strace by using the ptrace system call:
https://blog.nelhage.com/2010/08/write-yourself-an-strace-in-70-lines-of-code/
I have a linux executable running on my Ubuntu Machine. I want to grant access to a user in order to execute the program, but I don't want this program to be copied.
I was thinking into making a simple crypter app that will decrypt the program at run time an run it from memory.
Is this feasable ?
You can
chmod -r program
The executable will still be runnable, but you cannot copy it.
I just tested that on Ubuntu 14.04 with a downloaded eclipse binary - it worked.
Please note that this will only work for binaries. It will not work for script files that need to be read and interpreted by a shell or interpreter.
It depends hard on the kind of attack a potential user would be able to do which relates typically to the commercial value of a successful attack.
First of all:
If a user have physical access to the storage there is no chance to protect anything from copying. Simply by booting with another OS make all system internal protections baseless. This will be true for the protected program and also all the programs which do some kind of obscure security features like decryption. You can boot a pc from usb or any other media. Forget about something like rights managements supported by the OS.
To hack the mac address on a pc is something that can be done in a few seconds. Load a kernel driver which register a pseudo network card and you will get any fake mac you want. Who will protect the pc for running with modified kernel?
The next is, that any kind of decryption will result in a memory map which hold the executable during runtime of the prog. Any low privileged hacker can get a copy of this memory and can create a application to get this image to run on any other machine.
As you can see on real world licensing models, the only chance is to use additional hardware which is fully secured like crypto usb sticks or other kind of ciphering agents. Another trick can be some kind of online key repository. But all this can not be done by simply implementing some crypto algos.
If you have a product which must be protected against illegal usage, you have to use a commercial protection.
Sorry that I can not see which is your intention from your question. If you only want to keep a simple application with no commercial value on one pc for a "friend" or you have to secure the income of your business :-)
If I'm understanding, you have a user logged in who needs to run program X but not copy program X?
One way, if this is a compiled executable, is to set execute only, but double check your suid_dumpable kernel setting.
If it's a script, or if you have configuration files that go along with it and those need protection, then the /etc/shadow pattern applies: users need to be able to read that file, but not copy it elsewhere for attack. For this pattern, the solution is to use a mediator program. Specifically, the program can temporarily increase its privilege to read the file, but cannot be coerced into providing access to anything in the file beyond what exactly is needed to run.
The accepted answer to this question explains nicely the variety of options. I personally like the sudo approach.
I remembering reading this concept somewhere. I do not remember where though.
I have a file say file.c, which along with other files I compile along with some other files as a library for use by applications.
Now suppose i compile the same file and build it with a Kernel module. Hence now the same file object is in both user space and kernel space and it allows me to access kernel data structures without invoking a system call. I mean i can have api's in the library by which applications can access kernel data structures without system calls. I am not sure if I can write anything into the kernel (which i think is impossile in this manner), but reading some data structures from kernel this way would be fine?
Can anyone give me more details about this approach. I could not find anything in google regarding this.
I believe this is a conceptually flawed approach, unless I misunderstand what you're talking about.
If I understand you correctly, you want to take the same file and compile it twice: once as a module and once as a userspace program. Then you want to run both of them, so that they can share memory.
So, the obvious problem with that is that even though the programs come from the same source code, they would still exist as separate executables. The module won't be its own process: it only would get invoked when the kernel get's going (i.e. system calls). So by itself, it doesn't let you escape the system call nonsense.
A better solution depends on what your goal is: do you simply want to access kernel data structures because you need something that you can't normally get at? Or, are you concerned about performance and want to access these structures faster than a system call?
For (1), you can create a character device or a procfs file. Both of these allow your userspace programs to reach their dirty little fingers into the kernel.
For (2), you are in a tough spot, and the problem gets a lot nastier (and more insteresting). To solve the speed issue, it depends a lot on what exact data you're trying to extract.
Does this help?
There are two ways to do this, the most common being what's called a Character Device, and the other being a Block Device (i.e. something "disk-like").
Here's a guide on how to create drivers that register chardevs.
I apologize in advance for the long-winded question but I wanted to make sure I didn't leave out any key points that may alter your response.
I am responsible for maintaining system software written in 'C' of which we have a few common '.a' libraries. We have what I would call an "Execution Manager" who's main job is to fork and and exec a variable list of "test-job" executables and return control back to the Execution Manager once the test-job process terminates. All executables, including the execution manager, are statically linked against the aforementioned libraries. The execution manager and the test-job processes it forks use IPC via shared memory. One of the common libraries contains wrapper functions to create and attach the shared memory with a predefined key that never changes.
A few months ago we locked down our software (test-jobs plus execution manager), compiled them statically and released them to have the test-jobs "proofed". Since that time, there have been some requests for changes to be made to the execution manager which would require changes to a select few common library functions. However, management has decided that they do not want to recompile the test-jobs against the new version of the common libraries because that will require them to re-proof the test-job executables they currently have; and they do not want to expend the money to do that.
Since all executables were statically compiled, I would normally say mixing an Execution Manager with test-jobs statically compiled against different versions of the same common library would not be a problem. However, the inclusion of IPC via shared memory is making me wonder if that is still true. My gut says that as long as there were no changes to the shared memory wrapper functions, especially the key, then we should be OK, but I could really use some expert opinions on this.
Thanks for taking the time to read this, much appreciated.
You should be OK, as long as the data structures and protocols that define how the processes talk to each other over the shared memory have not changed. (That is, your little ABI that exists between the two processes).
I'd like to confirm what caf says. You have correctly identified the crucial bits: the key and the wrapper functions used to access the shared memory. These bits don't care whether they're defined in a .o file, whether they're part of a .a file, or where they are within a .a file. At link time, they get pulled into the exe, keeping their original functionality; their "temporary home" in a .a file doesn't affect how they find the shared memory segment, how they determine the relevant offsets, etc. So if these (i.e., the key and the wrapper functions) haven't changed, you should be set.