Shared memory allows other programs to influence each other by sharing a piece of memory
The concept of memory protection has become a well-accepted one in OS design. A special CPU component, the MMU (Memory Management Unit), provides each user-space application with a "virtual" address space. Each application "thinks" it has the whole address space for itself.
In reality, the MMU maps each "virtual" address to a "physical" one, usually in units of "pages" (4k or 2 or 4MB on the IA32 architecture). Page 0 of one application is mapped to physical 0x0007 0000, while page 0 of another application is mapped to physical 0x0008 0000. You get the idea.
This means that applications cannot communicate with (pass data to) each other directly, because they are "virtually alone" in their address space: They have to ask the OS kernel to pass a message (data). (Only the kernel and services in the kernel address space can see the real address spaces)
Now, Message Passing can be costly, in terms of clock cycles. If two processes intend to closely cooperate, the penalty of passing messages back and forth can become significant. An alternative would be to share memory.
To do this, the kernel is asked to map a certain address range of process A to the same physical address as a similar sized address range of process B. This address range is thus shared between process A and process B.
There are many things to consider here: Authentication, for example. Or that, if the shared physical memory is not mapped to identical virtual address ranges in process A and process B, any pointers in the shared memory structures must be offsets instead of absolute pointers, or they will no longer point to the same thing in the other process' address space. Also, on a multiprocessor system, checking to see whether the other process is accessing the memory at the same time is important.