Problem in "dacl of security descriptor of service" on 9.2.7?

Usage and Config
1

Ok, after my rollback from 9.5.1 I ended up on client 9.2.7 (which is new in my environment) and I think I might be encountering another inspector issue in this version. I’m retrieving a Service DACL and comparing it to the string I expect it to be. But I’m getting a wrong answer on at least one of my new 9.2.7 client machines, and it seems to evaluate differently between 9.2.7 and 9.5.1 - implies a difference between 9.2.7 and 9.5.1

Actual value:

C:\temp>sc sdshow tapisrv

D:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCLCSWLOCRRC;;;IU)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)

On a single machine, using the 9.5 Debugger and the 9.2.7 Client, the Fixlet Debugger will yield different results depending on whether I’m in “Local Fixlet Debugger Evaluator” or “Local Client Evaluator” modes -

//Local Client Evaluator -
q: (dacl of security descriptor of service "TapiSrv") as string = "D:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCLCSWLOCRRC;;;IU)"
A: False

// Local Fixlet Debugger Evaluator -
q: (dacl of security descriptor of service "TapiSrv") as string = "D:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCLCSWLOCRRC;;;IU)"
A: True
T: 1.172 ms

So then I try to display the DACL, and it looks the same either way -

// client
q: dacl of security descriptor of service "tapisrv" as string
A: D:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCLCSWLOCRRC;;;IU)

// debugger
q: dacl of security descriptor of service "tapisrv" as string
A: D:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCLCSWLOCRRC;;;IU)

So, thinking maybe it was some kind of weird whitespace/unprintable character thing (which shouldn’t happen retrieving a DACL), I tried wrapping it in quotes, and this shows a problem -

// Debugger
q: "%22" & dacl of security descriptor of service "tapisrv" as string & "%22"
A: "D:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCLCSWLOCRRC;;;IU)"

// Local Client
q: "%22" & dacl of security descriptor of service "tapisrv" as string & "%22"
A: "D:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCLCSWLOCRRC;;;IU)

…the closing doublequotes don’t appear at all when evaluating it in “Local Client Evaluator” mode.

It’s not a big problem for me - most of my clients are still between 9.2.1 and 9.2.2. It’s really only my Relays that I had upgraded to 9.5, then downgraded to 9.2.7 that are being affected by this. But is it a known problem? It seems to be working in 9.5, at least in the Fixlet Debugger.

I’m not sure whether this is specific to DACLs or a more generic string handling problem. I don’t seem to be able to append to a string-casted DACL which implies something wrong is going on but no error is thrown -

q: "%22" & dacl of security descriptor of service "tapisrv" as string as trimmed string & "%22 HOWDY"
A: "D:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCLCSWLOCRRC;;;IU)
T: 0.061 ms
2

When dealing with SACLs and DACLs you really need privilege to see the right answer so I’d say the answer coming from the local client evaluator is the going to be the right one as its running as LOCAL SYSTEM. If you elevate the fixlet debugger with PSEXEC then you might be able to simulate the answer.

As to the closing quote being missed it might be an artifact of the local evaluator connection.

Are the values of the following the same?

length of (dacl of security descriptor of service "tapisrv" as string)
3

Sorry if I didn’t make it clear…I was still investigating. The problem isn’t “Admin vs LocalSystem”, it’s “9.2.7 Client vs 9.5.1 Debugger”. After a little more research I can confirm that it’s an incorrect result from the 9.2.7 client. Versions earlier than 9.2.7, as well as 9.5.0 and 9.5.1 appear to be correct.

I’m seeing this problem impact my Fixlet Relevance for fixlets I’ve had working for quite some time. I’ve just repro’d in the command-line QnA 9.2.7 vs 9.5.0. The 9.2.7 is including 5 NULL characters %00 at the end of the DACL. It’s doing this for File DACLs as well. The GUI Fixlet Debugger appears to be truncating the string for display based on the NULL characters, but they are displaying in command-line QNA.EXE -

Q: version of client
A: 9.5.0.311
T: 1201

Q: ("%22" & it & "%22") of (dacls of security descriptors of services as string)
A: "D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)"
A: "D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)"
A: "D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)"

…
In 9.2.7, the terminating NULLS have to be included when doing string comparisons :frowning:

C:\Program Files (x86)\BigFix Enterprise\BES Client>qna
Warning: Current console font may not display locale characters correctly.
Q: version of client
A: 9.2.7.53
T: 5779

Q: ("%22" & it & "%22") of (dacls of security descriptors of services as string)
A: "D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)%00%00%00%00%00"
A: "D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)%00%00%00%00%00"
A: "D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)%00%00%00%00%00"
A: "D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)%00%00%00%00%00"
A: "D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)%00%00%00%00%00"

Q: exists (dacls of security descriptors of services as string) whose (it="D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)%00%00%00%00%00
")
A: True
T: 123271

Q: exists (dacls of security descriptors of services as string) whose (it="D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)")
A: False
T: 203498

Q: dacls of security descriptors of file "c:\program files (x86)\BigFix Enterprise\BES Client\besclient.exe"
A: D:(A;;FA;;;SY)(A;ID;FA;;;BA)(A;ID;FA;;;SY)%00%00%00%00
4

The only change I can find in that area at all occurred in the 9.2.5 release. Does the result change if you get an earlier version of FixletDeugger to try it?

5

I created an Analysis to track this across my deployment. Here are the results I’m seeing:

I see the problem in 9.2.5.130 and 9.2.7.53 on Windows 10 x64, Windows 2008 R2 x64, and Windows 7 x64

I see no problems with the following -
9.0.835.0 - win2008r2, win7
9.2.1.48 - win2003, win2008r2, win7
9.2.2.21 - win2003, win2008r2, win2012r2, win7
9.5.0.311 - win2008r2, win7

I opened a PMR - 21628,004,000. It’s not terribly pressing for me, I only have a few clients at the 9.2.5 or 9.2.7 versions; and I’d rather wait for 9.5.2 than go back to 9.2.2 on these. It appears to be fixed in 9.5.0 so as long as it doesn’t regress I’ll be ok with waiting.

If you have a 9.5.2 interim around that you can check on, I’m reporting an Analysis Property (False is good, True is bad):

    Name: 
test_dacl_of_service_null_char_bug

    Relevance: 
if windows of operating system then exists it whose (it as string ends with "%00") of dacls of security descriptors of services else false

Period: 1 day
6

Could you file a PMR for the 9.2.5+ problem? We do need to make sure the 9.2 branch is fixed even if the 9.5 one already is giving the right results.

7

Yes, I have it on file.