Just a conceptual question. A program file is compiled and linked with required libraries into an exe file. Now this file I understand is machine code, which the processor can understand. What I am curious about is how the OS plays a role. I would of thought the OS actually interprets the exe file ? I mean if I write a program in assembly, I could do modification on memory blocks anywhere, does the OS protect against this?
Yes the OS (specifically the loader) parses the executable file format. On Windows this is a PE (Portable Executable). On Linux, this is typically an ELF (Executable and Linkable Format) file. Generally, the OS doesn't concern itself with the actual code, however.
The loader determines which chunks of the program on disk go where in memory. Then it allocates those virtual address ranges, and copies the relevant parts of the file into place. Then it does any relocations required, and finally jumps to the entry point (also specified in the file format.)
The thing to remember is that most all modern OSes protect processes from one another by means of Virtual Memory. That means that every process runs isolated in its own Virtual Address space. So if Notepad writes to address 0x700000, he's not going to affect a variable that Word has at 0x700000. By the way these virtual addresses work, those actually map to totally different addresses in RAM.
On x86 platforms, this security is provided by the Protected Mode and Paging features of the processor.
The key is that it is the hardware that prevents you from doing anything "bad".
Peering Inside the PE: A Tour of the Win32 Portable Executable File Format
Microsoft PE and COFF Specification
ELF Specification
Related
In Linux for example, when the loader loads an application or library into RAM, doesn't this make everything writable then?
For example, the .text area of an executable file should be read only. Will it no longer be read-only after it is loaded into RAM? This I don't understand.
When an application or library is loaded into RAM, the loader makes a copy of the file in RAM. The copy is writable, but the original file on disk is still read-only.
The .text area of an executable file is read-only because it contains the machine code for the program. Once the program is loaded into RAM, that machine code is executed directly from RAM, so it doesn't need to be read from the disk again.
In my home folder in Linux I have several config files that have "rc" as a file name extension:
$ ls -a ~/|pcregrep 'rc$'
.bashrc
.octaverc
.perltidyrc
.screenrc
.vimrc
What does the "rc" in these names mean?
It looks like one of the following:
run commands
resource control
run control
runtime configuration
Also I've found a citation:
The ‘rc’ suffix goes back to Unix's grandparent, CTSS. It had a command-script feature called "runcom". Early Unixes used ‘rc’ for the name of the operating system's boot script, as a tribute to CTSS runcom.
Runtime Configuration normally if it's in the config directory. I think of them as resource files. If you see rc in file name this could be version i.e. Release Candidate.
Edit: No, I take it back officially... "run commands"
[Unix: from runcom files on the CTSS system 1962-63, via the startup script /etc/rc]
Script file containing startup instructions for an application program (or an entire operating system), usually a text file containing commands of the sort that might have been invoked manually once the system was running but are to be executed automatically each time the system starts up.
Thus, it would seem that the "rc" part stands for "runcom", which I believe can be expanded to "run commands". In fact, this is exactly what the file contains, commands that bash should run.
Quoted from What does “rc” in .bashrc stand for?
I learnt something new! :)
In the context of Unix-like systems, the term rc stands for the phrase "run commands". It is used for any file that contains startup information for a command. It is believed to have originated somewhere in 1965 from a runcom facility from the MIT Compatible Time-Sharing System (CTSS).
Reference: https://en.wikipedia.org/wiki/Run_commands
In Unix world, RC stands for "Run Control".
http://www.catb.org/~esr/writings/taoup/html/ch10s03.html
To understand rc files, it helps to know that Ubuntu boots into several different runlevels. They are 0-6, 0 being "halt", 1 being "single-user", 2 being "multi-user"(the default runlevel), etc. This system has now been outdated by the Upstart and initd programs in most Linux Distros. It is still maintained for backwards compatibility.
Within the /etc directory are several folders labeled "rc0.d, rc1.d" etc, through rc6.d. These are the directories the kernel refers to to know which init scripts it should run for that runlevel. They are symbolic links to the system service scripts residing in the /etc/init.d directory.
In the context you are using it, it would appear that you are listing any files with rc in the name. The code in these files will set the way the services/tasks startup and run when initialized.
Every now and then security advisories are published, warning about the risks of DLL injection.
Is there a general way to protect against DLL hijacking? I'm not familiar with the topic but requesting an absolute filename instead of a relative should be enough to protect against malicious DLLs in the working directory, shouldn't it?
If one can overwrite the DLL in my installation directory, one could also overwrite my executable thus a signature check seams useless.
DLL hijacking can be achieved for apps that request an DLL without using an absolute path. This triggers a search process and by placing the compromised DLL higher in the search patch that the real version, it is possible to have execute malicious code. However, your installation directory should be first in the search path, so it does not seem to be applicable in your case. Nevertheless you should be careful when passing sensitive data to your DLL, for example passwords and usernames.
In DLL Hijacking If, instead of a relative path, programmers start using absolute path, the vulnerability will be reduced. Reading the absolute path, the Windows or any other operating system will not depend on system variables for path and will go straight for the intended DLL, thereby dismissing the chances of loading the same name DLL in a higher priority path. This method too, is not fail-proof because if the system is compromised, and the cybercriminals know the exact path of DLL, they will replace the original DLL with the fake DLL. That would be overwriting the file so that the original DLL is changed into malicious code. But again, the cybercriminal will need to know the exact absolute path mentioned in the application that calls for the DLL. The process is tough for cybercriminals and hence can be counted upon.
I have a VB.NET executable that I distribute via a ZIP file (along with other supporting files). When the ZIP is downloaded my instructions call for the file properties to be checked and un-blocked if needed. This really only applies to the executable in it, it is just easier to have the user un-block the ZIP file.
A large part of the time this instruction is not followed and I have to work with them to get it taken care of. There is another executable in the ZIP that copies files to where they belong and does some other work.
Can this application check if the main executable is blocked? If so, can it unblock it programmatically?
When Jenkins invokes maven build, /tmp fills with 100s of surefire839014140451157473tmp, how to explicitly redirect to another directory during the build. For clover build it fills with 100s of grover53460334580.jar? Any idea to over come this?
And any body know exact step by step to create ramdisk so I could redirect surefire stuffs into that ramdisk ? Will it save write time to hard drive?
Thanks
Many programs respect the TMPDIR (and sometimes TMP) environment variables. Maybe Jenkins uses APIs that respect them? Try:
TMPDIR=/path/to/bigger/filesystem jenkins
when launching Jenkins. (Or however you start it -- does it run as a daemon and have a shell-script to launch it?)
There might be some performance benefit to using a RAM-based filesystem -- ext3, ext4, and similar journaled filesystems will order writes to disk, and even a quick fd=open(O_CREAT); unlink(fd); sequence will probably require both on-disk journal updates and directory updates. (Homework: test this.) A RAM-based filesystem won't perform the journaling, and might or might not write anything to disk (depending upon which one you pick).
There are two main choices: ramfs is a very simple window into the kernel's caching mechanism. There is no disk-based backing for your files at all, and no memory limits. You can fill all your memory with one of these very quickly, and suffer very horrible consequences. (Almost no programs handle out-of-disk well, and the OOM-killer can't free up any of this memory.) See the Linux kernel file Documentation/filesystems/ramfs-rootfs-initramfs.txt.
tmpfs is a slight modification of ramfs -- you can specify an upper limit on the space it can allocate (-o size) and the page cache can swap the data to the swap partitions or swap files -- which is an excellent bonus, as your memory might be significantly better used elsewhere, such as keeping your compiler, linker, source files, and object files in core. See the Linux kernel file Documentation/filesystems/tmpfs.txt.
Adding this line to your /etc/fstab will change /tmp globally:
tmpfs /tmp tmpfs defaults 0 0
(The default is to allow up to half your RAM to be used on the filesystem. Change the defaults if you need to.)
If you want to mount a tmpfs somewhere else, you can; maybe combine that with the TMPDIR environment variable from above or learn about the new shared-subtree features in Documentation/filesystems/sharedsubtree.txt or made easy via pam_namespace to make it visible only to your Jenkins and child processes.