I recently found that in Microsoft .NET framework an impersonated thread is not allowed to request "time at which the current process was started". This could be done intentionally or this could be some implementation deficiency.

Is there any security risk if any code run on a server is able to find when the process this code is running in was started?

  • Your title and question differ if I understand the question. Are you really asking about "everyone" or introspection within a process? Process isolation is an important security fundimental so allowing everyone access would be problematic. It seems you are asking about the code checking itself however. Can you clarify?
    – zedman9991
    Commented Mar 18, 2013 at 12:21
  • @zedman9991: Whatever. What if a "malicious user" knows when my server process was started or something like that is what I want to know. Impersonation, credentials, all that stuff are all implementation details.
    – sharptooth
    Commented Mar 18, 2013 at 12:43

3 Answers 3


Beyond the general "don't tell anybody anything" advice, which is entirely true, there are a couple interesting things about process start time from an attacker's point of view.

  • if you manage to crash a process, its start time will be reset. You could use that info to figure out which other attacks were working.

  • some systems have had vulnerabilities where they use the process start time as a seed for crypto random number generation - Netscape had a bug like that a long time back. If you knew a system did that, the process start time would be extremely useful.


Given the question of a “malicious user" knows when a process started is that a security issue the answer is yes. If an attacker can parse through the processes start times he is already deeper into the system than a secure configuration should allow.

For this question let’s assume that process start time is the only detail available to the attacker. An unrealistically artificial constraint but perfect for focusing on the value of start time for the attacker.

By parsing the start times and focusing on the longest running he can quickly narrow down kernel related processes that started at system boot which is valuable information. The ability to watch external attempts for access via web services or remote access attempts by locating the processes relative to the access attempt using start times would be valuable as well. Locating these processes enables the attacker to focus his efforts against the resources tied to these processes in order to attempt to gain the privileges and/or access the trusted details related to them.

Now let’s step away from the artificial constraint of just looking at start times and discuss the value of processes opacity to the defender. Sandboxing is just exactly that and the gold standard for securing systems from external attacks securing trusted processes from untrusted processes (isolating your secure banking browser tab from your casual surfing tab). Sandboxing is created by limiting process access to other processes even ones it spawned as in the case of tabs on a web browser application to only the essential details needed to make the functionality work.


Nice question, seems like one needs to do some creative thinking here. Consider this (i may be wrong)

Suppose process A which does the authentication and Process B does the authorization.

taking in consideration the IAA(identification, authentication and authorization) principal the programer naturally wants the authentication process to be followed up with authorization and not the other way around. Now, the way authorization works that it is dependent upon some time-based policy more of the same thing in concept in routers where you see it as Policy-Based ACLs.. Here, the time when the authorization process starts is critical as it defines user right to access the application or a resource.

The entire system allows access to object based upon context, so the attacker in that case can retrieve the time related information, probably through social engineering attacks that user (x) is the site administrator and remotely logins in at certain hours of the day. Using this information the attacker he can know either do one of the following :-

  1. Sniff the traffic
  2. Brute-force weak passwords policy.
  3. Find a web-application bug/ (sql injection)
  4. Using an already compromised server he can perhaps write a script to turn on sniffing when he sees process B in memory.

This scenario perhaps is localized, and is dependent upon environment variable but entirely plausible to your statement regarding what you said could be a security risk or not.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .