2

I know that C/C++ allows almost any part of memory space to be manipulated using pointers. But is it possible to use a pointer to access text or kernel section of the memory space. It would seem like there should be some-kind of safe guards against those sections since otherwise wouldn't it be possible to change the compiled program dynamically, which would automatically crash it I would presume, or crash the whole system in the case of changing something in the kernel?

EDIT: The question is referring only to modern systems employing MMUs.

Improve this question
14
  • 3
    AFAIK due to virtual memory, most desktop C programs can't access to other processes memory, let alone the kernels. Embedded systems, however, may not have virtual memory. Commented Aug 23, 2014 at 15:18
  • 1
    You can certainly access your own programs text sections, at least on all systems not using separate code- and data- addressspaces (That means just about all but really ancient ones, and maybe some embedded ones). But unless there's no memory-protection (many embedded systems) or you asked the platform to map kernel-space / other-programs-space into yours, you cannot access those. Commented Aug 23, 2014 at 15:21
  • This will certainly give you an overview: What happens when a computer program runs?. Commented Aug 23, 2014 at 15:22
  • 1
    Your first sentence is blatantly wrong. Neither C nor C++ allows you to access anything via pointers unless you can obtain the address via well-defined arithmetic on pointers obtained via the & operator, decay, or returned by standard functions. If you happen to obtain access to something else, that's via undefined behavior. C and C++ do not limit the impact of undefined behavior to a sandbox, but real operating systems with memory protection have some guarantees that even in the event of undefined behavior, the scope of access will be limited. Commented Aug 23, 2014 at 17:49
  • "access text or kernel section of the memory space" -- these are not the same sort of thing; very different considerations apply. You need to learn about the concept of "address space". Notably, you didn't mention the memory of other processes. As for @R..'s comment ... he's blunt, but his statement is factual ... focus on the facts if you're here to learn something rather than personally attacking people for their style. Commented Aug 23, 2014 at 19:50

3 Answers 3

Reset to default
2

Security and prevention of vulnerability in a computer depends on the cooperation of several components: (1) the computer hardware, (2) the operating system, and (3) the application programs. Since security and prevention of vulnerability require additional time and money most uses of computers, especially personal computers back in the 1980s and 1990s had a fairly open architecture.

For instance, an IBM PC or clone using an Intel 8080 or 8086 would be running the MSDOS operating system or some variant. Many applications would modify various areas and tables within the BIOS area as well as the MSDOS operating system. This was possible because the architecture of the CPU presented memory as a single shared resource and the operating system, which was quite simple and straightforward, provided minimal security and protection against vulnerabilities. The hardware did not support virtual memory or address translation so all applications running had to be well behaved and exercise self restraint. There were accepted guidelines about how to chain interrupt handlers so that multiple applications would be able to coexist in the same physical memory area and be notified of events or interrupts for which they were looking.

This Wikpedia article, x86 Memory Segmentation, describes the evolution, from a memory addressing perspective, of the Intel x86 processor family from the 8086 to later versions such as the 80286 which began to introduce hardware support for address translation.

However modern CPUs of any complexity provide a multitude of mechanisms for security to support virtual memory and the management of virtual memory isolating applications. With the original IBM PC and its clones, all applications shared the the physical memory. Modern CPUs provide a virtual memory space for each application with the CPU translating individual memory accesses within the virtual memory space into actual physical memory locations. The result is that applications run in their own virtual memory space and it requires operating system mechanisms to allow cooperating applications, each running in its own virtual memory space, to have a shared memory region.

The goal of these mechanisms is to isolate individual applications as much as possible so that if they do something foolish, the only application that is affected is the application itself and not other applications that may be running. The most important effort is to ensure that applications can not affect the operating system so that the operating system stays up and running even if an individual application crashes.

There is nothing to stop an individual application from modifying itself. The idea is that if an application wants to modify itself then it should be allowed to do so so long as the consequences are limited to the application itself. In some cases regions of virtual memory may be marked as read only which would cause an exception if an attempt is made to modify the data or program code in the read only area.

Another use of read only areas is from this paper by Thompson, UNIX Implementation, in which the read only area or text section in UNIX terms, is a loaded once and shared between multiple processes. This is an interesting, historical paper providing a thumbnail sketch of one of the most influential monolithic (not kernel based) operating systems around, UNIX, which became quite successful and which was imitated by a number of other operating systems. This stackoverflow question/answer, Unix/Linux Loader Process, provides some additional details about the loader and how a process loads.

However anyone who has dealt with a buffer overrun problem has seen that an application can modify its own memory area, usually with catastrophic results on the application.

Take a look at the Intel 64 and IA-32 Architectures manuals for details about the Intel architecture.

Malware and viruses are applications that use various vulnerabilities and exploits within operating systems. Stuxnet is a famous example (see IEEE Spectrum The Story of Stuxnet as well as this Wired article How Digital Dectives Deciphered Stuxnet, the Most Menacing Malware in History) as is Flame, both of which seem to be cyberwarfare applications.

Also see this Wired.com article on a USB malware, Why the Security of USB is Fundamentally Broken which outlines a malware attack through a modification of USB firmware. There is a link to some of the work being done by the NSA in the United States.

Here is a simple example showing what can be done in C using C-style casting. This example will compile with Visual Studio 2005. If you run this in the debugger, you will see that it will hit the int 3 instruction to cause a break point hit.

int jjFunc (void) { int i = 3; return i; } // 0xCC is an int 3 instruction for causing a break point. unsigned char xxFunc [] = {0xcc,0,0,0,0}; int _tmain(int argc, _TCHAR* argv[]) { int (*xx)(void) = jjFunc; char *p = (char *)xx; // point to my tiny program in memory xx = (int (*)(void))&xxFunc[0]; xx (); jjFunc (); *p = 0; jjFunc(); return 0; }
Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

"There is nothing to stop an individual application from modifying itself. " -- This is simply wrong, especially in the context of this question about "text ... section", which you never address. Nor do you ever mention the word "kernel".
@JimBalter, I provided a sample program which uses a C-style cast to jump into a writable memory area at which point by modifying the code in that area, I can create a self modifying application at the binary code level bypassing read only text sections. There are other levels of application modification such as SQL Injection or script modification such as the ubiquitous eval() statement. I used the phrase operating system rather than kernel since it is a more inclusive term covering a wider range of variations of operating systems and their components.
@RichardChambers Thank you for taking the time to write all this out. Very informative answer. I really appreciate the code section.
"I provided a sample program which uses a C-style cast to jump into a writable memory area at which point by modifying the code in that area" -- but it has nothing to do with the question ... which, again, was about the text section, and which you didn't answer. We're all aware that it is possible to change a program's data, so that's not what is meant by "modifying itself". Executing data is a different issue altogether -- and there are plenty of questions and answers at SO about such exploits and how operating systems can guard against them by making the data and stack unexecutable.
2

It is not possible to access kernel memory from any program, not even a C or assembly program. Modern operating systems employ a technology called virtual memory that essentially lets each program pretend it has all the computer's memory for itself. All the memory a program can see belongs to it.

Notice that most operating systems provide a mean for programs to access kernel memory, but your program needs to have an elevated permission level (e.g. super user / root / administrator) to be able to do that.

Improve this answer

11 Comments

You forgot about all OSes running without the benefit of memory-protection.
From how OP asked the question he asked, I guessed that he refers to the "ordinary" situation on a CPU with MMU and a multi-user operating system. If this assumption is wrong, I would be happy for OP to speak up.
@FUZxxl Yes, you're right, I was referring to the "ordinary" situation.
"Notice that most operating systems provide a mean for programs to access kernel memory" -- No, they don't. @Stochastic13 Programs always have read but not write access to their text sections ... there are no root privileges that can change that. The closest you could get is to modify the executable or library on disk before loading it.
@Stochastic13 You can read the text section but usually not write it. You can make the text section writeable with the mprotect call, but this won't let you modify the executable on disk.
|
-2

Operation System And CPU Prevent to acess kernel and interrupt table address in memory but if your user be in ring0 are you can,like bootloader program that use this section but outside the operation system ,but if there is stackoverflow bug or something vulnerability like that in os service like lsass or any other that have ring0 or better(system in windows) permission you can access to these memory area with use security vulnerability

Improve this answer

3 Comments

You also forgot about all OSes running without the benefit of memory-protection. In addition you did not mention that under some circumstances the OS allows mapping of the kernel to userspace. Please read the comments on the question.
Could you please answer in complete sentences with grammar that makes at least a little sense? It is very hard to understand your answer as-is.
We're very tolerant at SO of non-native speakers, but this goes beyond the limit. Please get help with your English so that you can be a useful contributor here ... clearly you have relevant knowledge.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.