A forum for reverse engineering, OS internals and malware analysis 

Forum for discussion about kernel-mode development.
 #9766  by madaboo
 Sat Nov 19, 2011 7:55 pm
Hello!

Assumig one kernel module is creating reg key with ZwCreateKey, but just after that it is creating security_descriptor with following parameters:
BYTE Revision =1 ;
SECURITY_DESCRIPTOR_CONTROL Control = 4 (DACL_PRESENT)
PSID Owner = 0
PSID Group = 0
PACL Sacl = 0
PACL Dacl = 0
and sets security descriptor for reg key handle with ZwSetSecurityDescriptor().

Is it possible to delete this key with another kernel module?
Do you thnink using here ZwOpenProcessToken() to take token of current process, then ZwAdjustPrivilagesToken with restore priviledge and then trying to remove key could solve the problem? I read somewhere that it is one of the ways to bypass DACLs?

Thanks a lot for help!
 #9773  by Vrtule
 Sun Nov 20, 2011 9:23 am
Yes, SeRestoreNamePrivilege should work on Windows 7. I am not sure about previous OS versions.

However, If you want to remove the key from kernelmode, you do not need to obtain this privilege. AFAIK security descriptors are not checked when your previous mode is KernelMode unless the kernel is explicitly asked to do it.
 #9774  by a_d_13
 Sun Nov 20, 2011 10:04 am
Vrtule wrote:Yes, SeRestoreNamePrivilege should work on Windows 7. I am not sure about previous OS versions.

However, If you want to remove the key from kernelmode, you do not need to obtain this privilege. AFAIK security descriptors are not checked when your previous mode is KernelMode unless the kernel is explicitly asked to do it.
Hello,

This is true. Using ZwCreateKey from kernel-mode will not check access rights, unless OBJ_FORCE_ACCESS_CHECK flag is passed to InitializeObjectAttributes. See here and here for more info.

Thanks,
--AD
 #9868  by madaboo
 Wed Nov 23, 2011 10:02 pm
Guys thank you so much for help!

One additional question.
Assuming that we're developing top level driver and we're trying to open key that was created without OBJ_FORCE_ACCESS_CHECK.
This is case where driver is called within callers thread context, so my question is if in this case security checks are performed or not? I mean in this situation previous mode is user-mode and not kernel mode and I would like to know if you think that in this case security checks should be performed.