DACL, null or not null

Last week, when hbifts was tossing his file ing encapsulation class, it encountered the problem that the kernel object created by the desktop program could not be opened directly in ASP. NET.

Memory ing files and User Permissions

The method was to modify the ASP. NET configuration file and let ASP. net play the role of a System Administrator Account to access the object. I replied to shuimu that this is a very bad programming habit, because it will make ASP. NET pages run in the out-of-control security context. Once a page is attacked by malicious code, the page will have System Administrator privileges, which is very dangerous. IIS 5/6 proposes various isolation models to minimize the loss caused by PAGE attacks in order to reduce the similar problems in the default models of IIS 4/5.

After accepting the improvement suggestions, hbifts adopted another method that is less harmful but should not be recommended. It solved the problem by setting up a null DACL.

Create an everyone security_attributes

This method can be said to be very close to the correct solution. Haha, although there are some security risks, there is already a qualitative breakthrough than the previous one.

At that time, I promised to write an article to introduce the solution. Unfortunately, I have been very busy for work and other reasons.
From the hbifts exploration process and replies from many friends, many people are unfamiliar with DACL and related permission control. Next, we will briefly introduce some basic knowledge and some basic concepts in this area, so that you can understand and understand what is actually used.

When nt loader was loaded into the kernel, the system started various system processes. At this time, most processes are controlled by the system. When speaking the same language, there is no gap between them. However, Winlogon is not an honest process. You have to provide a login interface to allow outsiders to log on to the system, and then derive seven or eight processes, such as explorer and cstrike, different languages are used to do different things, and resources such as file networks are randomly accessed. The NT system is not as bullied as a 9x generation: "If you want to mix on my website, you should first report your name. I have to say what you can do, you have to make a report for threats ".
Therefore, the user must provide creden when logging on to the system. The default password is the authentication token, fingerprint, Iris, and so on. However, it would be too troublesome to re-authenticate the access object and press the password to press the fingerprint. Therefore, from the login to logout period, each account starts to send a temporary credential, which is the origin of the session. For unified management, the NT system also sets up corresponding sessions for computer processes and service processes. Each account creates one session for each type of login. At ordinary times, you seem to have only one user logging on to the system with an account, but there are actually a bunch of processes running in the background with a bunch of sessions.
A typical session during system running is as follows. I will write a separate article about the development of this tool and detailed descriptions of fields.

Kesession-1.0.0.0-show kernel sessions @ Jul 12 2004
(C) 1999-2004 nsfocus Corporation. All Rights Reserved

Logon session 00000000: 000003e7 [999]
User name: sky \ flier $
Auth package: NTLM
Logon type: (none)
Session: 0
Sid: S-1-5-18
Account name: nt authority \ System
Logon Time: 2004-7-14 11:12:20
Logon Server:
DNS domain:
UPN:

Process file name
388: smss.exe
460: winlogon.exe
504: services.exe
516: lsass.exe
736: svchost.exe
...
3624: inetinfo.exe

Logon session 00000000: 0000cda3 [52643]
User name: nt authority \ Anonymous Logon
Auth package: NTLM
Logon type: Network
Session: 0
Sid: S-1-5-7
Account name: nt authority \ Anonymous Logon
Logon Time: 2004-7-14 11:12:32
Logon Server:
DNS domain:
UPN:

Logon session 00000000: Running cfc1 [53185]
User name: flier \ Administrator
Auth package: NTLM
Logon type: Interactive
Session: 0
Sid: S-1-5-21-3978760259-2706837669-145014315-500
Account name: flier \ Administrator
Logon Time: 2004-7-14 11:12:32
Logon Server: flier
DNS domain:
UPN:

Process file name
1628: assumer.exe
...
1612: kesession.exe

Logon session 00000000: Running a56a [42346]
User name:
Auth package: NTLM
Logon type: (none)
Session: 0
Sid:
Account name:
Logon Time: 2004-7-14 11:12:20
Logon Server:
DNS domain:
UPN:

We can see that the first login session 999 is the user name sky \ flier $, logging on to the system with the account nt authority \ system, that is, the account of my computer. In the past, NT systems did not have the concept of computer entities. At the beginning of 2000, computers themselves could also exist as independent entities, especially in AD. The computer account is a familiar system account. Most of the system processes, such as SMSs and Winlogon, are executed in the session again. The other is the user's login account flier \ administrator. Its login type interactive indicates that it is logged on to the console through the mouse and keyboard. There are also some other sessions, such as the network login nt authority \ Anonymous logon is used for anonymous login to obtain information. In the past, NT4 did not support computer physical login. You can only obtain information of other machines through anonymous connection.
Another thing worth noting is that each session has a SID that identifies a user account, a fixed S-1-5-18, a well-known Sid like a S-1-5-7, and a machine-related Sid like a S-1-5-21-3978760259-2706837669-145014315-500, I will not explain it in detail, or it will take a long time.

When logging on to the system, each account obtains information about its own permissions, that is, what can be accessed and what cannot be accessed. However, this does not seem to be enough, as if an ASP. NET process sometimes needs to assume another account to access special resources, or a process can adjust its permissions within the permitted range. If the account permissions are stored at the session level, a process will have to increase the permissions, and the other will have to change the complexity (competition ). In order to mediate disputes, we can only make three major boards each. Each process sends a copy of the CND (token), and each process needs to change it by itself. The thread Level in the process also has a similar problem, but it is not sent by default. If necessary, apply for it by yourself.

This token is very useful. It registers the user name and group information of the current user, the account privileges, and the default object permissions that we need to pay attention to here. Jeffrey Richter and Jason clark provide a very powerful tool in Chapter 11th user context in programming server-side applications for Microsoft Windows, Token master, you can view the tokens of any process or thread in the current system ).
The following is a typical default object permission setting that allows processes under the system administrator account:

**************************************** ****************************************
Token default DACL
**************************************** ****************************************
Access Allowed builtin/administrators
Access_mask: 00010000000000000000000000000000
Generic_all

Access Allowed nt authority/System
Access_mask: 00010000000000000000000000000000
Generic_all

That is, if the lpsecurity_attributes lpattributes parameter is null when a new kernel object is created in a system administrator account, by default, only the account, Administrator group, and system account have full access permissions. If
If the program View opens and accesses this object, it will be rejected. This is why hbifts cannot be stored in ASP.. Net to open the file ing object created by the desktop program, because its desktop program is generally run under the system administrator account, only the system administrator group and system account can access the created object. For security purposes, ASP. NET runs the ASP. NET page under the ASPNET account. It is not a member of the system administrator group and thus cannot access this object.

The first method played by hbifts is actually a solution. By setting ASP. net script to Make ASP.. Net runs under the system administrator account, so that the CNNIC of the thread where the page is running will be changed to the system administrator temporarily, so that you have the permission to process it. However, because the configuration file is configured to play a large role, the entire page will play an administrator account throughout its life cycle, which is very insecure. Even if you want to use this method, you should also use windowsidentity. the impersonate method is a fine-grained control. When you need to access an object, it dynamically assumes the role of a system administrator. After completing the operation, it is restored to the security context of the original account. However, this is not safe.

The general idea is to specify the access permission when creating an object. However, the second solution of hbifts is too much. It creates a null DACL security descriptor, that is, an object that allows anyone to access. Especially for objects that are used to interact with data such as file ing, enabling this level of permissions leaves a huge gap for malicious code. They can simply open this object, fill in some junk data or attack data, and use this object to communicate with the two-party program. In the past, I successfully completed a certain personal firewall in a similar way. By operating on its internal mutex, the firewall is still working outside of you by deceiving the communication between the engine and the interface, but it has actually been stopped.

To alleviate this problem, you must specify special permissions for the account running ASP. NET when creating an object. You can use the configuration file to provide the System ASP. NET account name, and then add access permissions to this account when creating an object. In its article cross-process access to shared memory permission, jiangsheng forcibly specifies that everyone (security_world_sid_authority) can access this object to solve the problem. Although this type of permission management is relatively extensive, it is slightly better than the null DACL in the previous article. null DACL is a non-fortified object that can be accessed by anything other than everyone.

The better way is to control the access of the target process in fine granularity, which is roughly divided into the following steps:

1. Get the token of the current thread or process
2. Get the SID of the token user
3. Obtain the SID of the ASP. NET Running Account
4. Set the DACL of the Security Descriptor
5. Create an object using the Security Descriptor

The instance code is as follows (for ease of demonstration, debugging and error handling code are ignored, and only the most basic check is retained ):

The first step is to first try to obtain the thread token, because as mentioned above, the token can be set to the Thread level, and the thread itself may be playing another account. If the thread does not have an independent token, try to get the process token. As for the permission to obtain the token handle, the query is sufficient to prepare for further obtaining the token information.

Handle htoken;
If (! Openthreadtoken (getcurrentthread (), token_query, true, & htoken ))
{
If (! Openprocesstoken (getcurrentprocess (), token_query, & htoken ))
{
STD: cerr <"unable to obtain process token" <STD: Endl;
Return-1;
}
}
Step 2: Obtain the SID of the token user. Gettokeninformation can query various associated information from the token, as shown in the user Sid we need here.

Typedef struct _ token_user {
Sid_and_attributes user;
} Token_user;

Typedef struct _ sid_and_attributes {
Psid;
DWORD attributes;
} Sid_and_attributes, * psid_and_attributes;

DWORD dwusersize = 0;
Gettokeninformation (htoken, tokenuser, null, 0, & dwusersize );

STD: String user (dwusersize, '\ 0 ');
Bool ret = gettokeninformation (htoken, tokenuser, (void *) user. c_str (), user. Size (), & dwusersize );

Closehandle (htoken );

Psid siduser = (ptoken_user) user. c_str ()-> User. Sid;

Step 3: obtain the SID Based on the ASP. NET running account. This is easy to use. It uses the hard-coded account name ASPnet. You can use the configuration file or directly read the system settings and configuration file for flexibility.
Const char * aspnet_account = "ASPnet ";

DWORD dwsidsize = 0, dwdomainsize = 0;
Sid_name_use use;

Lookupaccountname (null, aspnet_account, null, & dwsidsize, null, & dwdomainsize, & use );

STD: String Sid (dwSidSize-1, '\ 0'), domain (dwDomainSize-1,' \ 0 ');

Ret = lookupaccountname (null, aspnet_account, (psid) Sid. c_str (), & dwsidsize, (char *) domain. c_str (), & dwdomainsize, & use );

Psid sidaspnet = (psid) Sid. c_str ();

Step 4: initialize a security descriptor based on the previous two Sid values. Initializeacl initializes an ACL (any access control list) and adds the allowed ACE (Access Control item) with addaccessallowedace ). Here, both the Default User and ASP. Net user are granted the generic_all access permission, which can be further refined as needed. Finally, use this ACL to construct a Security Descriptor and set its DACL (Free Access Control List ).

DWORD dwaclsize = sizeof (ACL) + sizeof (access_allowed_ace) * 2 +
Getlengthsid (siduser) + getlengthsid (sidaspnet );

STD: String ACL (dwaclsize, '\ 0 ');

Initializeacl (PACl) ACL. c_str (), ACL. Size (), acl_revision );
Addaccessallowedace (PACl) ACL. c_str (), acl_revision, generic_all, siduser );
Addaccessallowedace (PACl) ACL. c_str (), acl_revision, generic_all, sidaspnet );

Security_descriptor SD;
Initializesecuritydescriptor (& SD, security_descriptor_revision );
Setsecuritydescriptordacl (& SD, true, (PACl) ACL. c_str (), true );

In addition, you can also use gettokeninformation and tokendefaultdacl to directly obtain the default DACL of the token, and then use setentriesinacl to directly modify it to generate a new security descriptor. However, this is troublesome. msdn provides a complete sample code. If you are interested, you can check it out.

Step 5 use this security descriptor to create a kernel object. You can use the process explorer tool provided by sysinternal to view the permissions of the objects created in this subroutine. We can see that the current user and the ASPNET user are added with the generic_all permission as expected.

Security_attributes SA = {sizeof (SA), & SD, false };
Handle hmutex = createmutex (& SA, false, "testmutex ");

Char ch;
STD: CIN> CH;

Closehandle (hmutex );

The general usage ideas are as follows. Many of the details can be discussed in depth. However, due to limited time and energy, I will skip this article for the time being. If you are interested, you can further discuss it.