Re: Debug privileges

It actually isn't too surprising, there are lots of poorly written client/server apps out there. People were often writing them that way to either keep all data in one place or use the superior computing power of the server, security wasn't something they were thinking of. It is unlikely you will be able to crutch the app to make it secure.

--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm


Samuel Ray wrote:
Thank you, Joe. I understand what you are saying.

The software we are working with is an accounting package that originated in DOS then converted Windows. It supports it's original API that was designed in a DOS world. Workstations access the server using the same program; the only real server component is the database such as SQL Server or DB2. The API however supports virtually everything that software using the API wants to do, and without auditing except for whatever logs that the database provides. So in other words, the software will do anything it is asked to do. It is secure to the extent that the API requires a login, but if a program can inject itself into the workstation's process then the program can use an existing session to use the API to do virtually anything.

We are not the vendors of the software but if it is possible for us to create server-side software that limits what can be done from workstations then I assume that can be valuable. The accounting software is being used by many customers. If the software is as much of a risk as it seems to be then it is sure surprising that it is used so much. This discussion helps to explain the problem and the opportunity. I hope it helps others too.


"Joe Richards [MVP]" <humorexpress@xxxxxxxxxxx> wrote in message news:OFOHWlAbHHA.2088@xxxxxxxxxxxxxxxxxxxxxxx
Well no the client software can't force the server software to do ANYTHING it wants, it can only ask it to do what the server software allows it to ask. If the client software has full access to tell the server what to do and the server is just taking any request and doing whatever is requested, yes, you have no security. But the server side should be validating the requests and only doing what makes sense, so for instance if the client tries to get the server to hand over internal IP type info, the server just won't do it.

To restate, the server side service should be written with the idea that the client is compromised, only send back or do at the request of the client what it knows to be safe unless it just absolutely has no way around it. For instance if you have a server app that it is valid for the client to ask for social security numbers and will do so when requested, if the client is compromised, there go your social security numbers. So then you ask yourself, does it really need to send back social security numbers, maybe it just needs to send back index values or key values that the client chooses later when it needs to do something with that SS# on the server.

--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm


Samuel Ray wrote:
That is more relevant to the topic.

The problem is that if the process that is executed in the workstations can call the server then the workstation process can get access to the application in the server. If a process executing in the workstation can use something such as a hook to get into the protected application then it can have essentially full access.

So is it necessary for the protected application to ensure that workstations don't have arbitrary access to the application executing in the workstations? Is that the only way to protect client/server applications? I don't mean to imply that that is all that needs to be done, I am saying that it is one of many things that must be done.

The particular third-party application I am working with does not do that. We would like to strengthen it's security but it seems impossible for us to do that; they must, right?



"Joe Richards [MVP]" <humorexpress@xxxxxxxxxxx> wrote in message news:ezVBrYRaHHA.1220@xxxxxxxxxxxxxxxxxxxxxxx
If all of the business logic and things you are afraid of being compromised are maintained on the server, these API calls don't matter.

--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm


Samuel Ray wrote:
Also, most (maybe all) of the functions that are of most concern are not client/server requiremets. For example ReadProcessMemory, WriteProcessMemory and other debugging functions. Also SetWindowsHookEx.


"Joe Richards [MVP]" <humorexpress@xxxxxxxxxxx> wrote in message news:OlHj1FCZHHA.4396@xxxxxxxxxxxxxxxxxxxxxxx
That is part of the draw of client server software... The client shouldn't have any rights on the server that they shouldn't normally have and any critical logic or IP is all handled on the server. Anything done on the local client is open to compromise. If you have a machine in your possession, you own the machine.

--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm


Samuel Ray wrote:
Thank you, Jos. That sounds logical and reasonable.

Except if the person starting a process is an employee and the actual owner is the employer, and situations such as that. That seems to be a big opportunity for the employee and others, but I assume that is what security specialists are needed for. If an employee executes a companie's accounting program and if the employee is the owner of the process then they can steal from the company. So I assume that all good accounting software does not execute under the typical employee's account.

I am being very simple here but I am a developer. If the description I have above is accurate, then understanding this will help me to know what to learn and it will help me guide (hopefully not too blindly) other developers.


"Jos Scherders" <thrower@xxxxxxx> wrote in message news:%23WK5lW3YHHA.992@xxxxxxxxxxxxxxxxxxxxxxx
Hi,

If you start the process you by definition have all the required privileges to debug. Just have a look all the ACL's attached to the process and match them with owner of the process.

Debug privilege basicly allows you open a process even if that process is owned by someone else. If you are the owner you dont need the debug privilege.

Jos

"Samuel Ray" <samuel@xxxxxxxxxxxxxxxxxxxx change_roadrunner_to_rr> wrote in message news:uQKBYn2YHHA.4872@xxxxxxxxxxxxxxxxxxxxxxx
Is it true that any process started by an account can use debugging calls for all other processes started by that account and there is no way to disable that? I am very surprised that that is true yet that is what people say.

Of course people also say that debugging calls require debugging privileges but WriteProcessMemory does not say that; it says the "handle must have PROCESS_VM_WRITE and PROCESS_VM_OPERATION access".

I am sorry for asking such a basic question, but I don't know where to look to get the answer and it seems that many people are confused.

.

Relevant Pages

  • RE: Client machines randomly locking up when printing
    ... constant, it occurs every day but not on all workstations, seems like one day ... > is a server or client side issue. ... click the Copy button and paste the full content to the Newsgroup. ...
    (microsoft.public.windows.server.sbs)
  • Re: What doesnt lend itself to OO?
    ... >> proxy and instructs the server to constuct the real object. ... rather than client code. ... If 'clock' is instantiated in the server, ... > for the server interface at the OOA level. ...
    (comp.object)
  • This is going straight to the pool room
    ... or not the client has privilege to do what they're trying to do, ... The server environment is this: ... 3GL User action Routines that Tier3 will execute on your behalf during the ... Routine Name: USER_INIT ...
    (comp.os.vms)
  • Re: New SBS2003 install, WIN2k client cant access internet
    ... SBS 2K3 server uses ISA server rather than Proxy Server, ... installed MS Proxy Server 2.0 client on the client workstation, ... >> Server, Windows XP client workstations work fine, the Windows 2K client ...
    (microsoft.public.windows.server.sbs)
  • Would SBS work for us?
    ... will need a beefy server HAL to handle all the remote ... >We are a travel agency with 14 workstations in our main ... >major location with 5 workstations also connecting to ... >(some in client offices and some at home) connecting ...
    (microsoft.public.windows.server.sbs)