SecureString CLR issue

[stanl]

I'm sure secure strings have been brought up before. Always willing to learn more about WB CLR:


[EDIT]... I visited this topic in 2019, but forgot that thread.

Code: Winbatch

method = 1 ;change to a different value for testing
string="GameofThrones"
ObjectClrOption("useany","System")
oSS = ObjectClrNew("System.Security.SecureString")
oSS.Clear()


For i = 1 To Strlen(string)
   objChar = ObjectClrNew("System.Char")
   ObjChar.Parse(StrSub(string,i,1))
   oSS.AppendChar(System.Char:ObjChar)
Next
n =  oSS.Length
Message("Secure String Length",n:@LF:oSS)


if method == 1
;this will work in Powershell, but fails - so I"m missing something
oPS = ObjectClrOption("useany","System.Runtime.InteropServices")
oPS1 = ObjectClrNew("System.Runtime.InteropServices.Marshal")
data = oPS1.SecureStringToBSTR(oSS)
Message("data pointer",data)
pw = oPS1.PtrToStringAuto(data)  ;fails here


else


;this will work but not display text
oPS = ObjectClrOption("useany","System.Management.Automation")
oPS1 = ObjectClrNew("System.Management.Automation.PSCredential","test",oSS)
pw =  oPS1.GetNetworkCredential.Password


endif


Message("Secure String Text",pw)


oSS=0
oPS=0
oSS=0
Exit
 

[td]

You likely have encountered a C# security attribute that considers raw memory pointers evil. It works in PS because PS is considered "safe" or fully trusted. If you follow Windows exploits at all, you also know that calling PS "safe" is only true in a very narrow sense of the term. So this is an example where PS does not translate to WIL CLR although there may be a way around it with more hoop jumping that is practical.

[stanl]

You likely have encountered a C# security attribute that considers raw memory pointers evil.

No. Missed that one. But anything we can learn w/out evil involved appreciated!!

[td]

If it is something you really want to do, you can always try the in-memory compiled assembly trick to wrap the offending method(s). Haven't tried it to workaround this sort of problem so don't know if it resolves this issue.

[stanl]

If it is something you really want to do, you can always try the in-memory compiled assembly trick to wrap the offending method(s). Haven't tried it to workaround this sort of problem so don't know if it resolves this issue.

Not really.. something I wanted to help some one out with WB script. I can just write and call it from PS. Thanks.

[td]

I had a few minutes and needed a break so I tested an in-memory compiled class version of the script and it still gave blank results. I suspect a C# executable would have the same problem unless created with the "secure" or whatever compiler switch and perhaps a manifest of some sort. Oh well.

One other note: on GitHub MSFT recommends that the SecureString class not be used on all future development. The explanation is a word salad but the gist is that it's not cross-platform compliment. Makes one wonder...

[stanl]

I had a few minutes and needed a break so I tested an in-memory compiled class version of the script and it still gave blank results. I suspect a C# executable would have the same problem unless created with the "secure" or whatever compiler switch and perhaps a manifest of some sort. Oh well.

One other note: on GitHub MSFT recommends that the SecureString class not be used on all future development. The explanation is a word salad but the gist is that it's not cross-platform compliment. Makes one wonder...

Interesting. For fun I ran a PS script for SecureString through PS 7 command line and it worked, so what does the future hold? But to clear things up, the person requesting help was not interested in a password, but more or less a secure text message from a file. Not sure how developed the request really was but that was why I started the earlier thread about the Caesar ciphor as an alternative.

[td]

Interesting. For fun I ran a PS script for SecureString through PS 7 command line and it worked, so what does the future hold? But to clear things up, the person requesting help was not interested in a password, but more or less a secure text message from a file. Not sure how developed the request really was but that was why I started the earlier thread about the Caesar ciphor as an alternative.

MSFT doesn't indicate that SecureString is going away just that it shouldn't be used. They usually (but not always) preserve functionality they don't want you to use. Instead, they have several "deemphasizing" tactics.

[stanl]

Thread can be closed as a moot point. Went the cipher route and my friend was happy with a working WB script.