I know that you can modify the ACL of a process to forbid termination. But if I do so in a program, I'm still able to "reset" these rights for example with the Process Explorer.
But for the Anti Virus Software that I use, this is not possible and I wonder why?
Even with the SYSTEM account I cannot read or write the "process permissions".
Any ideas how this can be forbidden and how I can get back the right to terminate such a program?
Related
Whenever one wants to attach to a process from Visual Studio, one receives this nasty message:
This question and its answers show the struggle to get rid of it. This Microsoft article tells us about the potential dangers of attaching for the debugging process/machine:
However, many developers do not realize that the security threat can
also flow in the opposite direction. It is possible for malicious code
in the debuggee process to jeopardize the security of the debugging
machine: there are a number of security exploits that must be guarded
against.
Question: how does the debugged process is able to exploit the debugging process? (I am interested in just a few highlights, as I imagine that one can write a book about it).
And also, what is the purpose of having this warning when debugging on local machine's w3wp.exe process (I imagine that the vast majority of debugging sessions happen within the development machine). If local machine's w3wp process is compromised, you are in deep trouble anyway.
You get this warning when you attach to a process that runs with a limited user account. Like w3wp.exe, a web server is typically configured with such account so that an attacker cannot do too much damage after he figured out how to compromise the web server. Note how you normally use an account with admin privileges to debug the web server.
This opens up a generic security hole that is very similar to the one exploited by a "shatter attack". A privilege escalation, the unprivileged process exploiting the privileges of another process. The conduit is the debugger transport, the channel that lets a debugger control the debuggee. I think a socket in the case where the process runs on another machine, a named pipe if it runs on the same machine. The compromised process could fake the messages that the debugger interprets as normal responses. Anything is possible, nothing is simple, none of this is documented. Intentionally.
Note how you still use the remote debugger when w3wp.exe runs locally. It is normally a 64-bit process and VS is 32-bit, the remote debugger (msvsmon.exe) is required to bridge the bitness difference.
It is the kind of attack scenario where Microsoft has to throw up their hands and can no longer guarantee that such an attack cannot succeed and do real damage to your machine. The attack surface is too large. So they display the dialog, you have to interpret it as a "we are no longer liable for what happens next". Plausible deniability when it ever comes to a lawsuit. The info it displays is not actually useful to judge whether the process is compromised, but it is all they got. Life is too short to worry about it every single time you click Attach, lawyers never once made a programmer's job easier :)
When you func eval something in the debuggee, you are effectively running code on the debugger. This is where the potential security problem could be.
For example, suppose the debuggee has some types that will load a natvis into the debugger. And suppose that the C++ Expression Evaluator has a security hole in it, that allows a buffer overrun attack through a natvis. Just by debugging a certain process, the remote process could take control of your local machine. Granted this isn’t likely, but the debugger isn’t hardened against this sort of attack. The nature of debugging means you have to let any code run.
In the other direction, once a process is being debugged, the debugger have the same permissions as it does. You can do anything you want.
This warning below pops up when attaching to an unknown users’ process. See this article:
https://msdn.microsoft.com/ro-ro/library/ms241736.aspx
I have some processes running on Windows 10 and I don't want them exit or close by anything inside or outside. I want to protect them. Anyone can tell me what I need to do or introduce me some tools to do this. Thank you so much
If you implement your "important" process as a service then a normal user will not be able to stop or kill it.
Preventing someone with administrator privileges from killing your process is very hard and I would recommend that you don't try to stop them.
Administrators can stop services, debug (and therefore kill) processes they did not start, run code as the system user and load kernel drives. There are only two ways to (try to) stop them:
If you are a real Antivirus/Antimalware vendor then you can create ELAM drivers and protected services. (Protected services can be debugged by a kernel debugger)
Create a kernel driver that prevents certain access rights when processes call OpenProcess and/or use dirty tricks to hide your process from the list of processes so it does not show up in task manager and other tools. Most people would consider this a pretty evil thing to do! You will have to fight with PatchGuard and Antivirus software if you try to do this.
Well, the title sumarizes my question, but I will elaborate. I have always thought that any process runing with no admin rights shouldn't be able to access the memory space of any other process, and of course shouldnt be able to halt it's execution.
However, with visual studio running under a non-privileged account, I am able to attach to some processes runing under the same account and debug them. Why is this possible? Shouldn't the operative system prevent this?
Thanks in advance and cheers
for access say memory space of any other process we need open process with PROCESS_VM_READ|PROCESS_VM_OPERATION|PROCESS_VM_WRITE .. for this not mandatory need have SE_DEBUG_PRIVILEGE - if process running in same session as debugger, have the same token - usually it security descriptor (DACL) let open it for this debugger. this is absolutely expected. so question here - are we can open process with full access for debugging ? if this "peer" process (running under same user, with same privileges) - why not ?
and from DebugActiveProcess function
The debugger must have appropriate access to the target process, and
it must be able to open the process for PROCESS_ALL_ACCESS.
DebugActiveProcess can fail if the target process is created with a security descriptor that grants the debugger anything less than full
access. If the debugging process has the SE_DEBUG_NAME privilege
granted and enabled, it can debug any process.
and remark from yourself - except protected processes, if only your debugger when called DebugActiveProcess also protected process (with not less level of protection) (yes this is possible debug protected processes also)
The program I'm using is dumping log-files which I'm then later unable to write to, if the program even manages to pick up the files. The problem doesn't seem to occur on machines where the infamous User Account Control is disabled, but I'm wondering if it's possible to find a list somewhere of the programs accepted by the UAC?
I am writing some testing software that receives some source code, compiles it on the server, executes it, forward input from the database, catches output and compares it with one in the database to see if it is correct. The problem is that source code can be anything (it is written in c/c++ and compiled with visual studio cl), so I need to prevent somehow malicious users. I am automatically killing those processes if they run longer than some time, or use more memory than allowed.
The question is, can I only allow those processes only to write and read from standard in/out streams and to deny any other access rights on windows.
Please excuse my English.
Thank you in advance.
Probably Job Objects can help you (see http://msdn.microsoft.com/en-us/library/ms684161(VS.85).aspx). This very powerful feature is not good known.
Working with jobs is very easy. You can create a job with respect of CreateJobObject and set a lot of different restrictions like time, memory and some restrictions. Then You can create a process with suspended flag, assign process to the job and resume the process. Then you receive full control under the created process and all tree of child processes, which the process can create. Job feature exist since Windows 2000.
Another modern way is User Interface Privilege Isolation (UIPI) (see http://msdn.microsoft.com/en-us/library/bb625963.aspx) or the way of usage Low Integrity Processes introduced by Vista. See http://msdn.microsoft.com/en-us/library/Bb250462#dse_stlip how to create a process with Low Integrity.