Can anybody tell me why Microsoft has made it necessary to always run
the "Remote Procedure Call" service despite the fact that I don't allow
anybody access to my computer via remote help? I understand that the
service accomplishes the following:

"...allows a computer program to cause a subroutine or procedure to
execute in another address space (commonly on *another computer" on a
shared network) without the programmer explicitly coding the details for
this remote interaction. That is, the programmer would write essentially
the same code whether the subroutine *is local to the executing program,
or remote.*"

Since my computer is NOT on a network (either business or home) I see
this as a serious security vulnerability. Or am I missing something?

--
John Corliss

"John Corliss" <q34wsk20******.com> wrote in message
news:8PidnddRId3sX3PXnZ2dnUVZ_tadnZ2d@posted.ccoun trynet...
> Can anybody tell me why Microsoft has made it necessary to always run the
> "Remote Procedure Call" service despite the fact that I don't allow
> anybody access to my computer via remote help? I understand that the
> service accomplishes the following:
>
> "...allows a computer program to cause a subroutine or procedure to
> execute in another address space (commonly on *another computer" on a
> shared network) without the programmer explicitly coding the details for
> this remote interaction. That is, the programmer would write essentially
> the same code whether the subroutine *is local to the executing program,
> or remote.*"
>
> Since my computer is NOT on a network (either business or home) I see this
> as a serious security vulnerability. Or am I missing something?
>
> --
> John Corliss

Hi
What do you think you are connecting to while you are
on the Internet?

chas2209

John Corliss wrote:
> Can anybody tell me why Microsoft has made it necessary to always run
> the "Remote Procedure Call" service despite the fact that I don't allow
> anybody access to my computer via remote help? I understand that the
> service accomplishes the following:
>
> "...allows a computer program to cause a subroutine or procedure to
> execute in another address space (commonly on *another computer" on a
> shared network) without the programmer explicitly coding the details for
> this remote interaction. That is, the programmer would write essentially
> the same code whether the subroutine *is local to the executing program,
> or remote.*"
>
> Since my computer is NOT on a network (either business or home) I see
> this as a serious security vulnerability. Or am I missing something?

Almost all calls between services and the user are handled by RPC.
RpcSs is not a critical NT service per se but almost nothing works on
Windows NT systems without it.

John

chas2209 wrote:
> John Corliss wrote:
>> Can anybody tell me why Microsoft has made it necessary to always run the
>> "Remote Procedure Call" service despite the fact that I don't allow
>> anybody access to my computer via remote help? I understand that the
>> service accomplishes the following:
>>
>> "...allows a computer program to cause a subroutine or procedure to
>> execute in another address space (commonly on *another computer" on a
>> shared network) without the programmer explicitly coding the details for
>> this remote interaction. That is, the programmer would write essentially
>> the same code whether the subroutine *is local to the executing program,
>> or remote.*"
>>
>> Since my computer is NOT on a network (either business or home) I see this
>> as a serious security vulnerability. Or am I missing something?
>
> Hi
> What do you think you are connecting to while you are
> on the Internet?

The internet is not a network per se. I've heard that argument before
too. Remember, RPC wasn't originally required in earlier versions of
Windows.

--
John Corliss

John John - MVP wrote:
> John Corliss wrote:
>> Can anybody tell me why Microsoft has made it necessary to always run
>> the "Remote Procedure Call" service despite the fact that I don't
>> allow anybody access to my computer via remote help? I understand
>> that the service accomplishes the following:
>>
>> "...allows a computer program to cause a subroutine or procedure to
>> execute in another address space (commonly on *another computer" on a
>> shared network) without the programmer explicitly coding the details
>> for this remote interaction. That is, the programmer would write
>> essentially the same code whether the subroutine *is local to the
>> executing program, or remote.*"
>>
>> Since my computer is NOT on a network (either business or home) I see
>> this as a serious security vulnerability. Or am I missing something?
>
> Almost all calls between services and the user are handled by RPC. RpcSs
> is not a critical NT service per se but almost nothing works on Windows
> NT systems without it.

John, thanks for replying. Yes, I'm aware that RPC handles calls between
processes and services, but it seems to me that inner-computer calls
could be handled discretely from inter-computer calls.

--
John Corliss

John Corliss wrote:
> John John - MVP wrote:
>> John Corliss wrote:
>>> Can anybody tell me why Microsoft has made it necessary to always run
>>> the "Remote Procedure Call" service despite the fact that I don't
>>> allow anybody access to my computer via remote help? I understand
>>> that the service accomplishes the following:
>>>
>>> "...allows a computer program to cause a subroutine or procedure to
>>> execute in another address space (commonly on *another computer" on a
>>> shared network) without the programmer explicitly coding the details
>>> for this remote interaction. That is, the programmer would write
>>> essentially the same code whether the subroutine *is local to the
>>> executing program, or remote.*"
>>>
>>> Since my computer is NOT on a network (either business or home) I see
>>> this as a serious security vulnerability. Or am I missing something?
>>
>> Almost all calls between services and the user are handled by RPC.
>> RpcSs is not a critical NT service per se but almost nothing works on
>> Windows NT systems without it.
>
> John, thanks for replying. Yes, I'm aware that RPC handles calls between
> processes and services, but it seems to me that inner-computer calls
> could be handled discretely from inter-computer calls.

On Windows NT systems RPC is an "interprocess" communication method. NT
systems are client/server systems, a process that makes a request to
another process is a client and the process that responds to the request
is a server, the the interprocess communication can be local or across a
network, they're all client/server transactions. Almost all Windows
services use RPC to communicate with each other. Maybe this can answer
some of your questions:
http://technet.microsoft.com/en-us/l...51(WS.10).aspx

John

John John - MVP wrote:
> John Corliss wrote:
>> John John - MVP wrote:
>>> John Corliss wrote:
>>>> Can anybody tell me why Microsoft has made it necessary to always
>>>> run the "Remote Procedure Call" service despite the fact that I
>>>> don't allow anybody access to my computer via remote help? I
>>>> understand that the service accomplishes the following:
>>>>
>>>> "...allows a computer program to cause a subroutine or procedure to
>>>> execute in another address space (commonly on *another computer" on
>>>> a shared network) without the programmer explicitly coding the
>>>> details for this remote interaction. That is, the programmer would
>>>> write essentially the same code whether the subroutine *is local to
>>>> the executing program, or remote.*"
>>>>
>>>> Since my computer is NOT on a network (either business or home) I
>>>> see this as a serious security vulnerability. Or am I missing
>>>> something?
>>>
>>> Almost all calls between services and the user are handled by RPC.
>>> RpcSs is not a critical NT service per se but almost nothing works
>>> on Windows NT systems without it.
>>
>> John, thanks for replying. Yes, I'm aware that RPC handles calls
>> between processes and services, but it seems to me that inner-computer
>> calls could be handled discretely from inter-computer calls.
>
> On Windows NT systems RPC is an "interprocess" communication method. NT
> systems are client/server systems, a process that makes a request to
> another process is a client and the process that responds to the request
> is a server, the the interprocess communication can be local or across a
> network, they're all client/server transactions. Almost all Windows
> services use RPC to communicate with each other. Maybe this can answer
> some of your questions:
> http://technet.microsoft.com/en-us/l...51(WS.10).aspx

Thanks John, but I think my question is then, why aren't processes on
another computer dealt with discretely from dealing with processes on
the same computer?

My computer is a single-user, non-networked computer. I never allow
anybody to have a remote assistance connection to my computer and have
the setting (My Computer/Properties/Remote/uncheck "Allow Remote
Assistance invitations to be sent from this computer") disabled. I also
have every service that has the slightest thing to do with remote
connections disabled:

Application Layer Gateway Service
Automatic Updates (I turn it back on whenever I manually update)
Error Reporting Service
Fast User Switching Capability
NetMeeting Remote Desktop Sharing
Remote Desktop Help Session Manager
(and more)

In the old days, I also used to block Remote Procedure Call, but as you
say, this can't be done with NT based versions of Windows. That's what
gets me. It's as if Microsoft is telling me that I don't have a right to
privacy on my own computer.

It still seems to me that making RPC handle inter-computer interprocess
communication regardless of whether or not one ever uses inter-computer
interprocess communication (in my case I don't, and if I ever find out
that it's going on in the background, I will disconnect from the
internet permanently) is a major security vulnerability.

Anyway, I guess this thread isn't going to change anything. I just have
to assume that my computer is compromised and take steps accordingly,
such as finding another operating system.

Thanks again for replying, John. Over and out.

--
John Corliss

John Corliss wrote:
> John John - MVP wrote:
>> John Corliss wrote:
>>> John John - MVP wrote:
>>>> John Corliss wrote:
>>>>> Can anybody tell me why Microsoft has made it necessary to always
>>>>> run the "Remote Procedure Call" service despite the fact that I
>>>>> don't allow anybody access to my computer via remote help? I
>>>>> understand that the service accomplishes the following:
>>>>>
>>>>> "...allows a computer program to cause a subroutine or procedure to
>>>>> execute in another address space (commonly on *another computer" on
>>>>> a shared network) without the programmer explicitly coding the
>>>>> details for this remote interaction. That is, the programmer would
>>>>> write essentially the same code whether the subroutine *is local to
>>>>> the executing program, or remote.*"
>>>>>
>>>>> Since my computer is NOT on a network (either business or home) I
>>>>> see this as a serious security vulnerability. Or am I missing
>>>>> something?
>>>>
>>>> Almost all calls between services and the user are handled by RPC.
>>>> RpcSs is not a critical NT service per se but almost nothing works
>>>> on Windows NT systems without it.
>>>
>>> John, thanks for replying. Yes, I'm aware that RPC handles calls
>>> between processes and services, but it seems to me that
>>> inner-computer calls could be handled discretely from inter-computer
>>> calls.
>>
>> On Windows NT systems RPC is an "interprocess" communication method.
>> NT systems are client/server systems, a process that makes a request
>> to another process is a client and the process that responds to the
>> request is a server, the the interprocess communication can be local
>> or across a network, they're all client/server transactions. Almost
>> all Windows services use RPC to communicate with each other. Maybe
>> this can answer some of your questions:
>> http://technet.microsoft.com/en-us/l...51(WS.10).aspx
>
> Thanks John, but I think my question is then, why aren't processes on
> another computer dealt with discretely from dealing with processes on
> the same computer?

There is a local procedure call (LPC) API, this is a scantly documented
Native NT API, as far as I can understand RPC communicates with this LPC
for local calls (or at least it did with NT 3.x and I think NT 4) but
this is seamless to the user or progaramer. These were design decisions
that were made and built in 1993 (or thereabouts) when Dave Cutler was
recruited to develop the NT platform. He and the members of his team or
Bill Gates and his OS strategy team would be able to tell you why they
decided to do things this way.

John

John Corliss wrote:
Hi John,

> Thanks John, but I think my question is then, why aren't processes on
> another computer dealt with discretely from dealing with processes on
> the same computer?

The original design rationale for RPC was to provide a generic form of
interprocess communication, which could be used both for processes on
one machine, or across multiple machines. The idea was that in a
networked group of machines a process could be moved from one machine to
another without needing to change to a totally different API. Process
location was defined by infrastructure (relatively flexible), not by
programming (relatively inflexible).

RPC was developed in several stages by Xerox, Sun and Apollo in the
early 1980s. By the late 80s it was a core component of the OSF DCE
(Distributed Computing Environment). When NT was being designed, it was
intended to be largely congruent with the current state-of-the-art in
workstation and midrange OS design; which included RPC. RPC isn't a
Microsoft invention; and OSs like Solaris, AIX and HP-UX also all run
RPC. NT's design also aimed for DoD Orange Book C2 security.

In short: RPC is a Good Thing, not a Bad Thing.

> In the old days, I also used to block Remote Procedure Call, but as you
> say, this can't be done with NT based versions of Windows. That's what

As long as you have Port 135 blocked in your firewall, no external
process will be able to communicate with the RPC end-point mapper. This
protects you against most possible exploits.

> gets me. It's as if Microsoft is telling me that I don't have a right to
> privacy on my own computer.

Well, privacy and security are two different things (although, granted:
somewhat related). As described in the DoD's Orange Book, *any* computer
connected to any network - even intermittently - is inherently insecure.
Having accepted that, the next stage is risk assessment, management and
mitigation. Absolute security is infeasibly difficult.

Microsoft actively maintains Security for RPC and has released many
fixes over the years to remediate possible exploits over RPC:

http://www.google.com.au/search?hl=e...microsoft.com&

> It still seems to me that making RPC handle inter-computer interprocess
> communication regardless of whether or not one ever uses inter-computer
> interprocess communication (in my case I don't, and if I ever find out
> that it's going on in the background, I will disconnect from the
> internet permanently) is a major security vulnerability.

If security researchers (both inside and outside of Microsoft) were
screaming about the security vulnerabilities inherent in RPC, Microsoft
would probably do something (like they did for Buffer Overruns, or
ASLR). But generally, most security folks accept RPC as a normal part of
the computing environment, and insist only that it needs to be robustly
secure - not eliminated.

> Anyway, I guess this thread isn't going to change anything.

True: Microsoft does not monitor this newsgroup for product feedback.

> I just have
> to assume that my computer is compromised

If you're running Windows XP and have all the current security updates
installed from Windows Update, and you occasionally run an anti-virus
and/or anti-malware tool, you should be reasonably free from risk of
compromise.

> and take steps accordingly,
> such as finding another operating system.

There may be many good reasons to use another operating system (and hey
- I have Windows, Mac OS X and Red Hat Linux all running on my desk, as
I type!). But the security risks of running RPCSs would not be one of
those reasons.

Hope it helps,

Andrew
--
amclar at optusnet dot com dot au