Not stopping at ANY breakpoints Win10 (1809) PowerShell v 5.1

This forum can be browsed by the general public. Posting is limited to current SAPIEN license holders with active maintenance and does not offer a response time guarantee.
Forum rules
DO NOT POST SUBSCRIPTION NUMBERS, LICENSE KEYS OR ANY OTHER LICENSING INFORMATION IN THIS FORUM.
Only the original author and our tech personnel can reply to a topic that is created in this forum. If you find a topic that relates to an issue you are having, please create a new topic and reference the other in your post.

Any code longer than three lines should be added as code using the 'Select Code' dropdown menu or attached as a file.
User avatar
Alexander Riedel
Posts: 6998
Joined: Tue May 29, 2007 4:43 pm

Re: Not stopping at ANY breakpoints Win10 (1809) PowerShell v 5.1

Post by Alexander Riedel » Tue Jul 02, 2019 11:11 pm

Hi Frank.

The communication with the debugger is IP port based using local host and it is obviously working since the error messages come back and the script runs, if I read this correctly.
The debugger simply uses Set-PSBreakpoint to set breakpoints and the number of error messages should be equivalent to the number of break- or trace-points set.
For most other debugger operations it also uses the official cmdlets since there is no actual debugger API in PowerShell other than that.

First thing we need is the output of the $psversiontable from a console on an affected machine.
Secondly, open a powershell console and
use
Set-PSBreakpoint -Script "whicheverscriptyouhave.ps1" -line <valid_line>
Then try to run the script and see if it stops there in the console.

Then try to debug a script in the ISE.

All this will tell us if the PowerShell installation on your machines is valid and operating.

My intuition tells me this is a permission issue. Somewhere (and I don't know where) your right to debug or use Set-PSBreakpoint is curtailed.
I do not know if this is a machine wide thing or a per process or per user thing, but that is my guess.
I would assume you tried to run PowerShell Studio elevated and tried there, yes?
Alexander Riedel
SAPIEN Technologies, Inc.

User avatar
FrankAndrew
Posts: 128
Joined: Thu Oct 26, 2006 7:00 pm

Re: Not stopping at ANY breakpoints Win10 (1809) PowerShell v 5.1

Post by FrankAndrew » Wed Jul 03, 2019 4:49 am

Hi Alex,

Now we are getting somewhere.

Below you will see the results of some of your questions:
(you know right where to look :) )

1. $PSVersionTable
2. LanguageMode (I think this is the root cause of the problem NOW that I see the next step does NOT work here)
3. results of "Set-PSBreakpoint" test. (Returns the EXACT text that we are seeing in the "Tools Output" panel)

2019.07.03_09-39-00_The_PowerShell_Set-PSBreakpoint_is_NOT_working_on_Win10.png
$PSVersionTable, LanguageMode and Set-PSBreakpoint results
2019.07.03_09-39-00_The_PowerShell_Set-PSBreakpoint_is_NOT_working_on_Win10.png (50.14 KiB) Viewed 1466 times
The ISE test went as follows:

When running in the ConstrainedLanguage mode the ISE would NOT let me toogle ANY breakpoints with the <F9> key or anything else.

When I ran it elevated, as a "Local Admin", I COULD set breakpoints and run in debug mode.

If I try to run PSS in elevated mode I would normally be using a different UserID that the one with which I am logged onto the LAN with. In that case that user does NOT normally have the network drive mapping that my other user has without mapping them first.

Our client OS people have also applied the ConstrainedLanguage mode to ALL network and local paths except a few exceptions for security reasons that I fully understand AND the LanguageMode is still set to Constrained when running in an interactive console but when running a PS1 script it allows FullLanguage mode. :)
Maybe that tells you enough about how the permissions are being restricted.
This brings up the question about how I/we can develop (and debug) in this new security environment.

My problem is that I need to be able to debug scripts while NOT being elevated!

On our Windows 7 Systems they did NOT restrict the language mode.

I will talk tomorrow with one of our Client Admin guys who set this rule to see if there is a way that they can allow the PSS to run in "FullLanguage" mode and be able to call the "Set-PSBreakpoint" cmdlet without being in "Local Admin" mode.

Maybe you know a way to do that.

Maybe you guys will have to test for the LanguageMode and if PSS is running in the ConstrainedLanguage mode then disable Debugging with an approriate message to us users so that we know WHY it cannot NOT work.

The ISE does NOT inform the user as to why, they just don't set the breakpoint markings.

I hope you are having FUN cause I AM! :) :| :)

User avatar
Alexander Riedel
Posts: 6998
Joined: Tue May 29, 2007 4:43 pm

Re: Not stopping at ANY breakpoints Win10 (1809) PowerShell v 5.1

Post by Alexander Riedel » Wed Jul 03, 2019 5:24 am

Glad we are getting somewhere here :D Admittedly that is the first time I encounter a machine or environment with the constrained language mode.
It is quite possible to add a warning, indicator or status bar field if that happens, but it seems quite rare.
I am itching to know why your OS people chose to do that. Maybe we can offer some feature that would alleviate their fears while still allowing debugging :D
Alexander Riedel
SAPIEN Technologies, Inc.

User avatar
Alexander Riedel
Posts: 6998
Joined: Tue May 29, 2007 4:43 pm

Re: Not stopping at ANY breakpoints Win10 (1809) PowerShell v 5.1

Post by Alexander Riedel » Wed Jul 03, 2019 5:33 am

Here is an excerpt from a blog post I found here, https://devblogs.microsoft.com/powershe ... uage-mode/, showing what this constrained mode prevents:

What does Constrained Language constrain?
Constrained Language consists of a number of restrictions that limit unconstrained code execution on a locked-down system. These restrictions are:

PowerShell module script files must explicitly export functions by name without the use of wildcard characters.
This is to prevent inadvertently exposing powerful helper function not meant to be used publicly.
PowerShell module manifest files must explicitly export functions by name without the use of wildcards.
Again, to prevent inadvertent exposure of functions.
COM objects are blocked.
They can expose Win32 APIs that have likely never been rigorously hardened as part of an attack surface.
Only approved .NET types are allowed.
Many .NET types can be used to invoke arbitrary Win32 APIs. As a result only specific whitelisted types are allowed.
Add-Type is blocked.
It allows the creation of arbitrary types defined in different languages.
The use of PowerShell classes are disallowed.
PowerShell classes are just arbitrary C# type definitions.
PowerShell type conversion is not allowed.
Type conversion implicitly creates types and runs type constructors.
Dot sourcing across language modes is disallowed.
Dot sourcing a script file brings all functions, variables, aliases from that script into the current scope.
So this blocks a trusted script from being dot sourced into an untrusted script and exposing all of its internal functions.
Similarly, an untrusted script is prevented from being dot sourced into a trusted script so that it cannot pollute the trusted scope.
Command resolution automatically hides commands you cannot run.
For example, a function created in Constrained Language mode is not visible to script running in Full Language mode.
XAML based workflows are blocked since they cannot be constrained by PowerShell.
But script based workflows and trusted XAML based workflows shipped in-box are allowed.
The SupportedCommand parameter for Import-LocalizedData is disabled.
It allows additional commands prevented by Constrained Language.
Invoke-Expression cmdlet always runs in Constrained Language.
Invoke-Expression cannot validate input as trusted.
Set-PSBreakpoint command is blocked unless there is a system-wide lockdown through UMCI.
Command completers are always run in Constrained Language.
Command completers are not validated as trustworthy.
Commands and script run within the script debugger will always be run in Constrained Language if there is a system-wide lockdown.
The DSC Configuration keyword is disabled.
Supported commands and Statements are not allowed in script DATA sections.
Start-Job is unavailable if the system is not locked-down.
Start-Job starts PowerShell in a new process and if the system is not locked-down the new process runs in Full Language mode.

The highlighted part may be of specific interest here.
Alexander Riedel
SAPIEN Technologies, Inc.

User avatar
FrankAndrew
Posts: 128
Joined: Thu Oct 26, 2006 7:00 pm

Re: Not stopping at ANY breakpoints Win10 (1809) PowerShell v 5.1

Post by FrankAndrew » Wed Jul 03, 2019 5:40 am

The reason for limiting the language mode is that in Constrained mode the pure .NET stuff that is NOT normally available in PowerShell will not be usable in an interactive console.

This would stop any Scripting kiddies (or grownups) from experimenting here inside the Company.

Anyone can read up in the Internet what is possible and then try it in ANY PowerShell console.

This does NOT stop them from writting a script with ANY text Editor and making the exact same calls but who knows that?

As you know PowerShell and .NET together are VERY powerful and you can read anything that you have rights to and who knows where everyone has rights??

Also if most developers run PSS evelvated then they won't see this either but the won't be able to debug a script that needs to run in this mode.

User avatar
FrankAndrew
Posts: 128
Joined: Thu Oct 26, 2006 7:00 pm

Re: Not stopping at ANY breakpoints Win10 (1809) PowerShell v 5.1

Post by FrankAndrew » Wed Jul 03, 2019 5:41 am

the only security that is REALLY good is when we pull the plug. :D

User avatar
FrankAndrew
Posts: 128
Joined: Thu Oct 26, 2006 7:00 pm

Re: Not stopping at ANY breakpoints Win10 (1809) PowerShell v 5.1

Post by FrankAndrew » Wed Jul 03, 2019 5:46 am

You sent:
Set-PSBreakpoint command is blocked unless there is a system-wide lockdown through UMCI.
Thanks, I will try to get our guys to allow PSS. :)

User avatar
Alexander Riedel
Posts: 6998
Joined: Tue May 29, 2007 4:43 pm

Re: Not stopping at ANY breakpoints Win10 (1809) PowerShell v 5.1

Post by Alexander Riedel » Wed Jul 03, 2019 5:51 am

Well, my opinion is that any security measure which forces admins into elevated mode MOST OF THE TIME is counter productive.
But then again, we have still people complaining that double clicking on a PS1 file doesn't run it by default, so I am not really surprised :D
Alexander Riedel
SAPIEN Technologies, Inc.

User avatar
FrankAndrew
Posts: 128
Joined: Thu Oct 26, 2006 7:00 pm

Re: Not stopping at ANY breakpoints Win10 (1809) PowerShell v 5.1

Post by FrankAndrew » Wed Jul 03, 2019 6:11 am

I agree and there is NO security measure that cannot be gotten around sooner or later. It just depends on how bad someone wants to get around it. But that is also the main goal of security is that it cost either too much time or money to get around it that there is little to NO benefit of going around in the first place.

I will let you know what I find out tomorrow.

Have a GREAT 4th of July tomorrow! We will be at work as usual here in Europe :)

User avatar
FrankAndrew
Posts: 128
Joined: Thu Oct 26, 2006 7:00 pm

Re: Not stopping at ANY breakpoints Win10 (1809) PowerShell v 5.1

Post by FrankAndrew » Thu Jul 04, 2019 4:01 am

Hi Alex,

I just found out from one of Client Admin guys that the logic being used to implement this security feature was developed here at our company using some of Microsofts standard protection mechanisms provided my Microsoft. It is the way that they combinded them that makes this work so well.

I asked them to give me a short description about what they do so that you guys can reproduce this situation and take it into consideration when PSS is running in a ConstrainedLanguage environment.
As I said above when the ISE is running in such an environment it DOES NOT let the end-user set ANY breakpoints AT ALL.

They have included my development machine in a special AD-Group so that it IS allowed to run in FullLanguage mode and with that I CAN debug again! :D :D

Thanks for the FAST help in getting to the ROOT cause of the problem.