Registry filter driver - Lower Access Granted in PostOpen

kyREcon · September 28, 2022, 12:59pm

Hi all,

I have gone through the documentation and coded my own examples, but it looks like what I just mentioned on the title cannot be done.

I am aware of STATUS_CALLBACK_BYPASS and how to dereference and replace an existing object coming from the Pre-Operation, and other actions that need to be taken for that matter.

However, it looks like STATUS_CALLBACK_BYPASS only works when we need to change the ReturnStatus of the PostOp, like from success to failure and viceversa.

In my example I am receiving a successful Pre-Operation where the granted access is KEY_ALL_ACCESS which I want to reduce to KEY_READ.

The following steps are taken:

Validate Pre-Op was successful
Validate access granted contains additional flags, not present in KEY_READ only, such as KEY_ALL_ACCESS .
Open a new handle to the same target registry key using ZwOpenKey and KEY_READ access.
Use ObReferenceObjectByHandle to get the object address from the handle opened in step 2.
Store this object in pPreInfo->ResultObject
Close handle opened in step 2.
Dereference pPostInfo->Object to delete original object
Replace pPostInfo->Object original object with pPreInfo->ResultObject (new object)
Set pPreInfo->GrantedAccess to KEY_READ
Set ReturnStatus to success
Return STATUS_CALLBACK_BYPASS

All the above completes without any errors. However, examining the usermode handle that is returned to the caller, ProcessHacker reports that access granted is KEY_ALL_ACCESS.

I have also verified that the object associated with the usermode handle is the new object we used to replace the original one.

In other words, everything looks fine from the coding point of view, so I am now thinking that changing the granted access is not actually possible and we can only either fail a successful Pre-Op, or make a failed Pre-Op to succeed by taking over the operation and redirecting to another key etc…etc…, depending on why it failed…etc…etc… You get the point.

Is my final conclusion correct?

Thank you,
kyREcon

Dejan_Maksimovic · September 28, 2022, 4:16pm

What do you mean by access granted in PreOp?
I might be missing something.

kyREcon · September 28, 2022, 4:48pm

@Dejan_Maksimovic said:
What do you mean by access granted in PreOp?
I might be missing something.

https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/ns-wdm-_reg_create_key_information_v1

Also please note there is a typo in the original first post: In steps 4, 6 where another step is referenced that is step 3 not 2.

Jeremy_Hurren · September 29, 2022, 12:19am

Changing the granted access should be possible based on what I have seen. Is it possible that you are testing with a create of a new key, in which case I think you always get full access to the created key?

Jeremy_Hurren · September 29, 2022, 2:20pm

Ok, so I looked into this a little bit more and I don’t think what you are trying to do is supported. The implicit contract appears to be that when a caller asks for KEY_ALL_ACCESS when you return success then that is what they are given. (OS code will take the modified GrantedAccess that you set, figure out which bits are missing/remaining from the original DesiredAccess, and when it creates the object handle it will ensure those access bits are set, giving you a handle with KEY_ALL_ACCESS even though you set it to KEY_READ.

There is a corner case where this all appears to work correctly, though. When a caller specifies MAXIMUM_ALLOWED as their desired access, you can change the granted access in your post-callback, and OS will honor that. Unfortunately, you can’t really create a complete solution based on that, though.

MBond2 · September 29, 2022, 10:36pm

I have no idea about the OP’s actual problem, but it is clear that if a caller requests KEY_ALL_ACCESS, the callee cannot succeed the request and also reduce the access to KEY_READ. MAXIMUM_ALLOWED is different since the caller has to know that they might not get as much as they want.

Think about how this could work. Other than an incorrectly coded application that requests lots of access that it does not need, any application that requests access on a handle intends to use it. You can’t say yes you can have the access you asked for, but at the same time no i didn’t really mean it

kyREcon · October 3, 2022, 8:31am

Thank you all for your comments. I was away and didn’t have access to my account.

@Jeremy_Hurren said:
Changing the granted access should be possible based on what I have seen. Is it possible that you are testing with a create of a new key, in which case I think you always get full access to the created key?

Definitely not the case, this is a PostOpen operation.

@Jeremy_Hurren said:
There is a corner case where this all appears to work correctly, though. When a caller specifies MAXIMUM_ALLOWED as their desired access, you can change the granted access in your post-callback, and OS will honor that. Unfortunately, you can’t really create a complete solution based on that, though.

I believe I had successfully tried this in the past and it did work, which made me wrongly assume that this would work with any access mask requested.

@MBond2 said:
Think about how this could work. Other than an incorrectly coded application that requests lots of access that it does not need, any application that requests access on a handle intends to use it. You can’t say yes you can have the access you asked for, but at the same time no i didn’t really mean it

Logically you have a point. However, in terms of filtering various operations this is not always the case. For example, you can modify the desired access on process and thread create handles callbacks and return a success status. So, this is actually possible with other ones as well and it’s also one of the main usages of such callbacks when filtering various operations, which are extensively used by security software for that exact purpose, such as self-protection from tampering etc…

Mark_Roddy · October 3, 2022, 2:30pm

I’m going to have to agree with other posters that if the open request is
asking for write access, for example, and the operation returns success,
then write access has been granted. Your filter driver can of course ignore
that and reject writes.

Mark Roddy

MBond2 · October 3, 2022, 10:40pm

Other than as a compatibility shim for a specific miscoded application, successfully completing a request for access while silently changing the access from what was asked for is malware. At best, it moves the site of the failure from the handle open to the handle use - which will screw with the error handling paths.

Most ‘security’ software is in fact malware, but anyways

kyREcon · October 5, 2022, 10:23am

@MBond2 said:
Other than as a compatibility shim for a specific miscoded application, successfully completing a request for access while silently changing the access from what was asked for is malware. At best, it moves the site of the failure from the handle open to the handle use - which will screw with the error handling paths.

Most ‘security’ software is in fact malware, but anyways

You are the usual forum troll that offers no technical value other than echoing yourself in a desperate search for approval.

You did exactly the same thing to one of my previous posts. You came by to state some shenanigans and left leaving behind nothing worthy to be remembered about.

I am amazed that you are still allowed to reply in forums like this, but please I am kindly asking you to stop replying to my posts.

Please save it for your ‘audience’.

Cheers.

Phil_Barila · October 5, 2022, 3:06pm

@kyREcon said:

@MBond2 said:
Most ‘security’ software is in fact malware, but anyways

[snip]

You are the usual forum troll that offers no technical value other than echoing yourself in a desperate search for approval.

[snip]

I am amazed that you are still allowed to reply in forums like this, but please I am kindly asking you to stop replying to my posts.

Please save it for your ‘audience’.

Personal attack against someone whose opinions you don’t like isn’t appreciated. Make a better argument or ignore it entirely, but the ad hominem just looks petty and fragile.

Phil B
Not speaking for LogRhythm, Inc.

Tim_Roberts · October 5, 2022, 5:17pm

Mr Bond is a long time and highly valued member of this community. He happens to be very opinionated, but he’s usually right. You ignore him at your peril.

kyREcon · October 5, 2022, 10:15pm

Personal attack against someone whose opinions you don’t like isn’t appreciated. Make a better argument or ignore it entirely, but the ad hominem just looks petty and fragile.

I am not here to look for “opinions”, but for technical and educated answers. @MBond2 either copies other people’s replies or never gives a straight answer other than converting a technical discussion to some theoretical approach for his own pleasure of engagement.

Mr Bond is a long time and highly valued member of this community.

Sorry to hear that.

He happens to be very opinionated

That’s a nice way to say he doesn’t know what he is talking about.

You ignore him at your peril.

Amen!

In any case I am here for technical discussions only. Listening to people echoing reddit and twitter opinions about how all security software is malware is the worst-case scenario I would ever expect from a “highly valued member”.
I am kindly asking @MBond2 to ignore any further posts of mine since he already failed to engage sensibly with both of my posts. I am looking at numbers here, and 2 out of 2 is 100% failure.

I appreciate the fact that you all wish to protect your buddy, but please don’t do it at the expense of people that post serious questions and expect serious answers.

I’ve had a great conversation with @anton_bassov at my previous post not because he is my friend, but because he gave sensible and technical answers.

On the other hand, @MBond2 joined the conversations to say:

** I have not read your post in detail**
the general presumption is that KM components have to be written ‘properly’ and not expose the system to vulnerabilities.

Good lord!!!

The facts are there for everyone to review. If you read his answers in both my posts and you find them technically adequate and sensible, I am happy to continue my endeavours into a more serious place.

Thank you.

kyREcon · October 5, 2022, 10:39pm

Many thanks to @Jeremy_Hurren for engaging in a sensible and technical manner in this discussion.

MBond2 · October 6, 2022, 1:02am

I’m sorry that my answer doesn’t meet with your approval. It is provided free of charge and you may take as much value from it as you deem fit.

Let’s assume that I’m wrong. Turn the question around. Other than a compatibility shim, what is the valid use of succeeding an open request, but really granting less or different rights than those that were requested?

Properly written programs will request the access that they need. If you say yes in the open, but then fail when WriteFile etc. gets called, then you shift the failure mode from one that is expected from the API contract to one that isn’t. Robustly written programs will handle those failures too, but many will simply fail or provide unintelligible error messages. Moving the failures from an API contract expected path to and API unexpected path is malware even if you have no other design

Improperly written programs may request way more access than they actually need. Helping them to request what they actually do is a compatibility shim and I have already granted that that is a valid use

What is the other valid use case am I missing?

Peter_Viscarola_OSR · October 6, 2022, 4:46pm

I spend a few days off the forum, and look what happens.

@kyREcon … Your reply to Mr @MBond2 is not acceptable. NOT, as in, stop it now if you value the ability to post here, as I will not tolerate a repeat incident.

Σας προειδοποιώ - μην επαναλάβετε αυτήν τη συμπεριφορά.

Did I make that clear enough?

Many thanks to the users who flagged the post. And my apologies for being slow to respond… I’ve been out of touch for a couple of days.

Thank you to messrs @Tim_Roberts and @Phil_Barila for their replies here.

Peter

kyREcon · October 7, 2022, 5:45pm

I am totally disappointed by looking at senior members and administrators defending someone that engaged in both my posts, that’s 100% if you know the math, and in both cases his answers were meaningless and quality degrading to say the least.

I have no interest in continuing this argument, but you can’t change my opinion about his behaviour regarding my posts.

As @Tim_Roberts mentioned it’s fine to be “highly opinionated”, and this is where I stand for regarding that user.

He engaged in both my posts literally like a troll.

Please allow me to provide an example from my older post, where I was having a serious conversation with @anton_bassov.

@MBond2 came by to say those two things exactly:

I have not read your post in detail
the general presumption is that KM components have to be written ‘properly’ and not expose the system to vulnerabilities.

Yes, that was his contribution to a series of technical replies and discussion.

I am just saying that this user is negatively impacting my experience on this forum and I am kindly asking him to stop engaging in my conversations, UNLESS he has something meaningful to say.

In this one, he came by to say that “all security software is malware”. Echoing dumb opinions found on reddit and twitter is not adding any value to this forum.

I know that you are now all on full “let’s protect our homie” mode, but the facts are there for everyone to review.

I have nothing personal against @MBond2 and I am truly sorry for any inconvenience I may have caused.

I just want to be able to enjoy this forum by having serious discussions.

Thank you all for your attention, and I hope there will be better days for all of us.

Tim_Roberts · October 7, 2022, 6:22pm

It is very rarely productive to engage in personality debates on a technical mailing list. The impersonal nature of email makes it way too easy for readers to extract connotations that were not intended. Those who are highly sensitive probably need to find another venue.

“all security software is malware”

He is not incorrect. The vast majority of kernel-bound security products do more harm than good. I have encountered quite a number of them in my dealings.

Peter_Viscarola_OSR · October 7, 2022, 7:01pm

Continuing to take this thread into realms that have absolutely nothing to do with the original question:

Mr @kyREcon : In my long, storied, and often boring career, it took me longer than usual to learn what I have found to be a useful set of lessons. One such lesson is that it’s usually easier to just ignore replies that I, personally, find add no value than to try to “fix” the behavior of the poster. If you think about it, “That was a stupid reply” doesn’t really accomplish anything, regardless of the correctness of the assertion. The poster clearly liked what they posted, and so will not agree with you. Objectively, either there IS value in the reply, and you don’t see it – in which case you excoriating the poster accomplishes nothing but makes you look silly – OR there IS truly NO value in the reply – in which case it is unlikely that you’re going to get the poster to see that and mend their ways.

Please don’t confuse this with the case when somebody posts something that is TECHNICALLY incorrect. In THAT case, it’s practically you DUTY to correct them (as nicely as possible, please).

Here’s my free advice: You get a reply that you don’t find helpful, just don’t READ it. If you really have an issue with a given member, ISTR that this forum (like most) even has a setting in which you can click on a given username and select “ignore”.

And, finally: When you have been here as long as Mr. @MBond2, and have posted nearly as many truly helpful replies as he has, then we’ll defend you too, regardless of what you post in any given specific instance.

Now that I’ve had my chance to philosophize and advise, let us return to our technical discussions.

Mark_Roddy · October 7, 2022, 7:08pm

What @MBond2 initially wrote, as did others, was:

I have no idea about the OP’s actual problem, but it is clear that if a caller requests KEY_ALL_ACCESS, the callee cannot succeed the request and also reduce the access to KEY_READ. MAXIMUM_ALLOWED is different since the caller has to know that they might not get as much as they want.

And that is the problem with the approach that your are taking, and you kept right on ignoring this point and insisting that you could reduce access rights requested and return success, You can’t do that and not break the API contract.

Also just stop the drama already.