Re: WriteProcessMemory and ReadProcessMemory

From: lelteto (lelteto_at_discussions.microsoft.com)
Date: 09/27/05 

Date: Mon, 26 Sep 2005 18:12:02 -0700

I think the only "authoritative" people here are from Microsoft when they
answer questions with full knowledge of their software (including source code
access).
We others just trying to to help - giving back a bit to the developer /
security community :)

Laszlo Elteto
SafeNet, Inc.

"Sam Hobbs" wrote:

> Thank you very much. I was nearly certain that this was the situation but I
> could not be totally sure. I can't speak authoritatively enough. On the
> other hand, you are definitely authoritative enough. It is an immense help
> to have your answer that you have provided here.
>
> I even wrote a message to the author of Writing Secure Code but he did not
> understand that I was asking because other people are advising other people
> to use WriteProcessMemory/ReadProcessMemory for IPC. I explained in a reply
> but that is as far as I got that way.
>
> In addition to Administrators, developers also need debug privilege, but you
> know that. I assume you would agree that good managers would reject software
> that requires debug privileges for all users of it (unless they would all be
> Administrators and/or developers due to the purpose of the software).
>
> As far as performance, shared memory is significantly more efficient, but
> that is off-topic for here. The only real advantage of
> WriteProcessMemory/ReadProcessMemory for IPC is simplicity for the
> programmer.
>
>
> "lelteto" <lelteto@discussions.microsoft.com> wrote in message
> news:387F19D9-1F24-4B72-868D-0B89E6B31FFC@microsoft.com...
> > The problem with these APIs is that they require DEBUG PRIVILEGE (in order
> > to
> > attach to the process). If you have this privilege than you can attach to
> > ANY
> > PROCESS including eg. virusscan, firewall, services etc. and can modify
> > their
> > behavior to your liking (eg. disable them). Obviously this broad "can do
> > anything" right is a security risk. (Well, if you are running as Admin on
> > the
> > computer you have this right anyway.)
> > If you want to use the memory for IPC communication than use SHARED MEMORY
> > (named or unnamed memory mapped files). The speed could be the same
> > (memory
> > access) but it doesn't have the security risk of touching the other
> > process'
> > code and/or normal data area.
> >
> > Laszlo Elteto
> > SafeNet, Inc.
> >
> > "Sam Hobbs" wrote:
> >
> >> In at least a couple of programming forums, programmers are advised to
> >> use
> >> WriteProcessMemory/ReadProcessMemory for IPC. My impression is that it is
> >> (they are) not a good solution for IPC.
> >>
> >> I won't try to convince someone that they should not use
> >> WriteProcessMemory/ReadProcessMemory for IPC, and I won't use
> >> WriteProcessMemory/ReadProcessMemory for IPC, but it seems to me that I
> >> should say something indicating that use of
> >> WriteProcessMemory/ReadProcessMemory for IPC is not a good solution.
> >>
> >> Is there any security-related potential problem with use of
> >> WriteProcessMemory/ReadProcessMemory for IPC? In particular, would use of
> >> WriteProcessMemory/ReadProcessMemory for IPC require use of a higher set
> >> of
> >> permissions in a manner that is a potential security risk?
> >>
> >> People say that use of WriteProcessMemory/ReadProcessMemory for IPC is
> >> not
> >> good, but no one has provided an explanation for why it is not good that
> >> is
> >> sufficient to use for advising others. In other words, it is foolish to
> >> post
> >> a comment that simply says that it is not good to use
> >> WriteProcessMemory/ReadProcessMemory for IPC. If it is not good, then
> >> there
> >> must be an eplanation for why it is not good.
> >>
> >>
> >>
>
>
>

Relevant Pages

  • Re: WriteProcessMemory and ReadProcessMemory
    ... In addition to Administrators, developers also need debug privilege, but you ... WriteProcessMemory/ReadProcessMemory for IPC is simplicity for the ... > If you want to use the memory for IPC communication than use SHARED MEMORY ... > access) but it doesn't have the security risk of touching the other ...
    (microsoft.public.platformsdk.security)
  • Re: Can you find anything wrong with this solution to the Halting Problem?
    ... TM that solves the halting problem as a similar process ... which does some form of IPC to determine its behavior. ... Given the source code for TM1, ...
    (comp.theory)
  • Re: Approaching the limit on PV entries
    ... On Mar 13, 2008, at 5:10 AM, Stephen Clark wrote: ... Enable/Disable locking of shared memory pages in core ... this sysctl can force SysV shared memory regions to be ... all of these are intended for normal usage or tuning, however...some reflect purely debugging interfaces which only do make sense in the context of the associated source code. ...
    (freebsd-stable)
  • Re: fork & exec: sharing memory between a parent and a child.
    ... > program I need to lock the shared memory region to make sure ... You have access to the source code and you can't troubleshoot it. ... How does the exec'ed program find out what semaphore to use? ...
    (comp.unix.programmer)
  • Re: STL and shared memory
    ... The T++ I've referenced seems to use a shared memory pool of a fixed size, ... if I correctly understood its source code. ... >> allocator has to have. ...
    (comp.lang.cpp)