Powershell by default
-
Microsoft Replaces Command Prompt with PowerShell in Latest Windows 10 Build
This could be the first step towards the demise of cmd
PowerShell officially replaces the Command Prompt in the Win + X menu, so when you right-click the Start menu, you’ll only be allowed to launch the more powerful app. Additionally, in File Explorer’s File menu and in the context menu that appears when pressing Shift + right-click in any folder, the old Command Prompt will no longer be available.
Typing cmd in the run dialog will launch PowerShell as well, so Microsoft has made a significant step towards phasing out the traditional Command Prompt.
The Windows PowerShell celebrates its 10th anniversary this week
[jeff'd from In Other News Today - bz]
-
@Zecc said in In other news today...:
Typing cmd in the run dialog will launch PowerShell as well, so Microsoft has made a significant step towards phasing out the traditional Command Prompt.
That must not be in this build (14971) yet... I just started cmd that way.
-
@Zecc said in In other news today...:
phasing out the traditional Command Prompt.
I wonder how many things will break...
-
@Zecc said in In other news today...:
Typing cmd in the run dialog will launch PowerShell as well, so Microsoft has made a significant step towards phasing out the traditional Command Prompt.
But Command Prompt is something only 0.000001% of Windows users use according to a survey, and even then those are "techy users". Real users, normal users, don't need advanced options that will confuse them. They just want Grumpy Cat. And that's why it's perfectly reasonable for Microsoft to only offer PowerShell.
-
@Lorne-Kates indeed but for people who have stuff based on CMD that can and does break in Powershell...
-
@Lorne-Kates said in In other news today...:
They just want Grumpy Cat.
When they can't successfully log in because IT's nasty old scripts break, they'll have Grumpy Cat indeed…
-
@Arantor said in In other news today...:
@Lorne-Kates indeed but for people who have stuff based on CMD that can and does break in Powershell...
I dare say that they won't do away with cmd completely. It'll just be hidden so that the default for anything new would be Powershell.
I mean, the article itself says how you can opt-out and return to the old setting which doesn't hide cmd.
-
@Rhywden something something RTFA something
something
-
@Rhywden the reason I currently don't do any PowerShell is that the machines at work have a policy of not letting them run PowerShell scripts, but bat files run just fine.
Dump security policies. Dunno if it's windows default or if the morons at itsec put it there.
-
@fbmac Probably the same kind of genius thinking which led them to disable Edge at my school while leaving InternetExplorer alone.
I still can't wrap my head around the kind of thinking which lead them to their conclusion.
Then again, I fully expect to have to tell them in one year: "Guys, don't you think it would be good to update the image to a reasonable patch level at least once in a while? Y'know, that virus scanner you installed - definition files one year old don't really serve much of a purpose."
-
@Zecc So Microsoft actually did today the thing that Blakey claims they did 10 years ago when they launched Vista.
Well, I'm happy for them. But the transition won't be complete as long as the recovery environment still only offers cmd.exe.
-
@Rhywden said in In other news today...:
Probably the same kind of genius thinking which led them to disable Edge at my school while leaving InternetExplorer alone.
I still can't wrap my head around the kind of thinking which lead them to their conclusion.
"We're used to supporting Internet Explorer. These new computers have Internet Explorer. But they also have something called Edge? Well, disable it... we'll just keep supporting Internet Explorer. That way we don't have to support 2 different browsers at once. Or learn anything new."
-
@fbmac said in In other news today...:
the machines at work have a policy of not letting them run PowerShell scripts, but bat files run just fine.
Dump security policies. Dunno if it's windows default or if the morons at itsec put it there.It's the Powershell default. It's completely fucking stupid.
I work around it by sticking this at the front of every PowerShell script:
<# : @echo off setlocal set "pscmd=$input | &{[scriptblock]::create((gc -readcount 0 "%~f0") -join "`n").invoke(@(&{$args} %*))}" endlocal & powershell -nologo -noprofile -c "%pscmd:"=\"%" goto :EOF #>Then, once my script is debugged and I'm happy with it, all I need to do before publishing it is change the file extension from
.ps1to.cmd.I got some of this as copypasta from here. I understand all of it except the section that will expand to
@(&{$args} an_arg another_arg "a third arg in quotes")I get that it's making an array to pass as the argument list to
.invoke, but I don't understand the meaning or purpose of the&{$args}part. If one of you PowerShell experts could enlighten me I'd be grateful.Experimenting shows that
$foo = @(&{$args} eeh ah ooh) $foooutputs
eeh ah oohand I'd really like to know exactly why.
-
Further experimenting shows that this produces the same output:
&{} eeh ah oohso it seems that if you invoke an empty scriptblock as if it were a cmdlet, you get its arguments returned as a list of strings. Which means I can get rid of the confusing use of $args and have my polyglot header reduced to this:
<# : @echo off setlocal set "pscmd=&{[scriptblock]::create((gc -readcount 0 "%~f0") -join "`n").invoke(@(&{} %*))}" endlocal & powershell -nologo -noprofile -c "%pscmd:"=\"%" goto :EOF #>Happy now. I'd be happier still if I could find that behaviour documented somewhere.
-
@flabdablet
Although if you have local admin, you can easily useSet-ExecutionPolicy RemoteSignedto run any PowerShell script that is signed by a trusted CA (regardless of source) or any PowerShell script that is "local" to your machine (regardless of signing -- though files downloaded from the Internet may still be blocked until you go into Windows Explorer, bring up the properties of the script, and check the box to "unblock this potentially dangerous file that was downloaded from the Internet", since PowerShell still considers it "Remote" until you unblock it like that).And even if you don't have local admin, you should be able to run
Set-ExecutionPolicy RemoteSigned -Scope CurrentUserin order to bypass the defaults for your user account.Or you can go whole hog and use some execution policies that will run anything (with or without a prompt when you run Internet scripts, there are options for both). I generally don't recommend those options unless you know you're dealing with a well trusted script; you shouldn't leave the Execution Policy as anything less restrictive than RemoteSigned as a system default, IMO.
Set-ExecutionPolicy (Microsoft.PowerShell.Security) - PowerShell
The Set-ExecutionPolicy cmdlet changes PowerShell execution policies for Windows computers. For more information, see about_Execution_Policies. Beginning in PowerShell 6.0 for non-Windows computers, the default execution policy is Unrestricted and can't be changed. The Set-ExecutionPolicy cmdlet is...
Edit to add: Also, as with all things Windows, if your company's Group Policy specifies a setting, you'd better learn to love it, because that's what you're stuck with, regardless of your local admin privileges.
-
@Arantor said in In other news today...:
@Lorne-Kates indeed but for people who have stuff based on CMD that can and does break in Powershell...
Then it's up to the elitists to rewrite in The One True Way, instead of being
who stand between Real People and their Grumpy Cat.
-
@izzion said in In other news today...:
if you have local admin, you can easily use Set-ExecutionPolicy RemoteSigned...
The point is that what a sysadmin wants a scripting tool for is to write scripts that just work without fuss.
I can't write a simple .ps1 script and just know that it's going to even try to work when a user double-clicks it or drags-and-drops files onto it; the target machine will typically need Things done to it first which, as you yourself point out, might not even be possible due to idiotic Group Policy settings.
The whole executionpolicy business is bullshit security-theatre, as evidenced by the fact that one can work around it by feeding command strings to powershell.exe via the -command parameter. They should have left it out. Anybody with malicious intent can wrap malicious PowerShell code in any number of ways that get past it, so all it actually achieves is wasted time for normal PowerShell scripters.
-
@Lorne-Kates said in In other news today...:
@Zecc said in In other news today...:
Typing cmd in the run dialog will launch PowerShell as well, so Microsoft has made a significant step towards phasing out the traditional Command Prompt.
But Command Prompt is something only 0.000001% of Windows users use according to a survey, and even then those are "techy users". Real users, normal users, don't need advanced options that will confuse them. They just want Grumpy Cat. And that's why it's perfectly reasonable for Microsoft to only offer PowerShell.
See, @blakeyrat was right all along that CMD was deprecated and should never be used in the 21st century!!!
-
So why am I by default not watching a thread "I created"?
Heck, why wasn't I even notified?
-
@izzion said in Powershell by default:
I generally don't recommend those options unless you know you're dealing with a well trusted script; you shouldn't leave the Execution Policy as anything less restrictive than RemoteSigned as a system default, IMO.
Right, because it will protect from malware... unless that malware author just uses .exe or .bat or .com or .hta or .msi or .js?
-
@anonymous234
Valid point, I guess. I also leave my car doors unlocked with the keys in the ignition, since there are plenty of other ways to steal my car anyway.
-
@flabdablet said in Powershell by default:
The point is that what a sysadmin wants a scripting tool for is to write scripts that just work without fuss.
Then sign them. What on earth's the problem? It's a one-time "fuss" (not even that much of one) and it encourages proper change management before you release something out to end users. If you can't change Group Policy and you can't get a code signing certificate from your domain CA, then you're apparently not in a position where your enterprise would like you to be writing scripts for other users to blindly execute anyway.
-
@heterodox said in Powershell by default:
Then sign them.
Still need default settings changed on target machines before this achieves anything. Also doesn't answer the objection that this entire mechanism is completely and utterly pointless.
-
@izzion said in Powershell by default:
Valid point, I guess. I also leave my car doors unlocked with the keys in the ignition, since there are plenty of other ways to steal my car anyway.
No, an equivalent metaphor would be to have a house and put iron bars only on the bathroom window in the second floor, for security.
-
@flabdablet said in Powershell by default:
Also doesn't answer the objection that this entire mechanism is completely and utterly pointless.
... no, it's not. You're not thinking big enough or objectively at all, and it rankles me when people get whingy about safe and sane security mechanisms. You really think the world in which anyone could just run a .cmd script without even thinking about it was a good world? One in which the .cmd script could get altered without your knowledge or permission?
Look, if you're scripting in PowerShell, you fall into one of two camps:
-
You're just scripting for yourself - Set your CurrentUser execution policy to RemoteSigned and shaddup about it. Or if you have local profiles everywhere, create an accompaniment .cmd script (since you'd like to be stuck back in that world) that just does powershell.exe -ExecutionPolicy RemoteSigned script.ps1 %*
-
You're scripting for others - You owe it to those others to sign your scripts. It identifies authorship, which is good for you, it gives some assurance that you thought the script was ready for consumption instead of a hastily-slapped-together pile of crap that should warn them about fourteen times before they run it, and it gives assurance that the script can't be tampered with and then happily delete all of their files next time it's run.
It's the same reason you should sign executables, because they're the same thing by now when PowerShell has access to the entire .NET Framework. Face it, we're moving towards a world in which the platform is secured from UEFI BIOS to the programs you run. We're not in the 1980s anymore where everyone's a "hacker". If you want to be a hacker now, you have to jump through hoops, and that's fine because you're not the common use case.
-
-
@heterodox said in Powershell by default:
It's the same reason you should sign executables, because they're the same thing by now when PowerShell has access to the entire .NET Framework
Exactly, so they should have the same security policy.
-
@anonymous234 said in Powershell by default:
@heterodox said in Powershell by default:
It's the same reason you should sign executables, because they're the same thing by now when PowerShell has access to the entire .NET Framework
Exactly, so they should have the same security policy.
PowerShell's a new technology so they can afford to start with a sane design and let everyone get used to it from the start. PE executables aren't. You'll notice the behavior when you download an unsigned vs. signed executable from the Internet getting more and more differentiated but it's going to be a longer transition before they can get near default-deny.
-
@Tsaukpaetra said in Powershell by default:
@Zecc said in In other news today...:
phasing out the traditional Command Prompt.
I wonder how many things will break...
Lots. Unless they've made some major changes to powershell recently. I don't use ps much so let's give it a try.
PS C:\Users\el_heffe\batch>
dns-open[error message in unreadable red-on-black-text[
Suggestion [3,General]: The command dns-open
was not found, but does existin the current location. Windows PowerShell does not load commands from the current location by default.http://i.imgur.com/4FqnpIw.png
http://i.imgur.com/SglRVEH.png
http://i.imgur.com/zyF63bC.gif
-
@heterodox said in Powershell by default:
You really think the world in which anyone could just run a .cmd script without even thinking about it was a good world? One in which the .cmd script could get altered without your knowledge or permission?
I'm saying that the executionpolicy mechanism leaves us in that same world. I'm not saying that some kind of control over script execution policy isn't a good idea - hell, even Linux has it in the form of executable bits - I'm saying that what MS built into PowerShell is so trivial to work around that they might as well not have bothered.
Script security is probably quite a good idea. What PowerShell's executionpolicy facility offers is not script security; it's a half-assed security theatre embuggerance. The correct metaphor is not iron bars or car locks, it's the TSA.
-
@flabdablet said in Powershell by default:
I'm not saying that some kind of control over script execution policy isn't a good idea - hell, even Linux has it in the form of executable bits - I'm saying that what MS built into PowerShell is so trivial to work around that they might as well not have bothered.
I think we're meeting about halfway here. Recall again that you're coming at it from the perspective of a local administrator. Of course it's easy to work around for you; it's supposed to be. In an enterprise a user can be prevented from changing the execution policy via Group Policy. They get to run Microsoft's scripts, the enterprise's scripts, and trusted third party scripts. Security and usability win.
-
@heterodox said in Powershell by default:
In an enterprise a user can be prevented from changing the execution policy via Group Policy.
And I come back again to the same point, which is that the execution policy is irrelevant given that powershell.exe can be invoked with a -command argument that completely ignores it.
If I wish to write something malicious in PowerShell, and hand it to drones in a locked-down enterprise to double-click and run, I can do that regardless of the PowerShell script execution policy.
I find it a little frustrating that you keep presenting reasonable arguments in favour of something that MS has simply not implemented, while ignoring the fact that all their half-implemented non-security actually achieves is to add pointless makework to a sysadmin's day. What they have done does not make PowerShell in any way secure. It just makes it less convenient for no security gain whatsoever.
-
@flabdablet said in Powershell by default:
And I come back again to the same point, which is that the execution policy is irrelevant given that powershell.exe can be invoked with a -command argument that completely ignores it.
I'm trying to assume good faith but you're being an imbecile here. The objective is to raise the bar for an attacker; there's no such thing as absolute security (+usability). There's got to be a balance. It's harder to hide something like powershell -Command "([ADSI]""WinNT://$Env:COMPUTERNAME/Administrators,group"").add(""$Attacker..."")" (pseudocode, for the pedantic, since I forget which type of argument that method takes) than something like "Hey, if you're having that problem with slow Web sites, double-click NetworkDiagnosis.ps1 and send me the results".
If I wish to write something malicious in PowerShell, and hand it to drones in a locked-down enterprise to double-click and run, I can do that regardless of the PowerShell script execution policy.
No shit, you can give them an EXE to double-click and run regardless of the PowerShell script execution policy. They're just trying to make sure when they're introducing new technologies that they want people to adopt (PowerShell scripts) that those new technologies come with a security framework that will meet a range of needs, from home user to enterprise.
all their half-implemented non-security actually achieves is to add pointless makework to a sysadmin's day.
Sorry you have to learn something new. That's the world we live in.
-
@heterodox said in Powershell by default:
"Hey, if you're having that problem with slow Web sites, double-click NetworkDiagnosis.ps1 and send me the results".
"Hey, if you're having that problem with slow Web sites, double-click NetworkDiagnosis.cmd and send me the results".
And NetworkDiagnosis.cmd is a PowerShell script with a few lines of polyglot glue tacked on the front that PowerShell sees as a comment, and it works by feeding itself to powershell.exe using the -command argument. So all I need to do to bypass PowerShell prohibitions on running .ps1 scripts is to rename the .ps1 I've just developed and tested as .cmd and it runs anywhere regardless of executionpolicy.
And in fact this is what I do because I cannot be arsed hand-holding my users through the process of fooling with the PowerShell execution policy on their home boxes. I just give them polyglot .cmd scripts to run at home, most of the code of which is PowerShell not cmd, and they Just Work.
-
@heterodox said in Powershell by default:
They're just trying to make sure when they're introducing new technologies that they want people to adopt (PowerShell scripts) that those new technologies come with a security framework that will meet a range of needs, from home user to enterprise.
But PowerShell scripts do not come with such a framework. They come with a half-assed bunch of trivially bypassable crap that exists only to tick a box on some sales droid's list of claimable features. It doesn't actually stop anything bad from happening so it might as well not be there. The fact that it is there is nothing more than another irritating little papercut that puts people off using the language.
If it worked as advertised then sure, there would be some point to it. But it doesn't. It's broken and useless and purely annoying.
-
@flabdablet said in Powershell by default:
"Hey, if you're having that problem with slow Web sites, double-click NetworkDiagnosis.cmd and send me the results".
That's not an argument about PowerShell, that's an argument about how security was not a consideration in the command interpreter's original design, and now it can't be tacked on without crippling everything written in the last few decades.
And NetworkDiagnosis.cmd is a PowerShell script with a few lines of polyglot glue tacked on the front, and it works by feeding itself to powershell.exe using the -command argument.
Likewise re this argument. And good for you, I guess? Security circumvention techniques can be utilized for convenience sometimes, but I'd argue if you're a white hat you have a duty to learn the right way to do it, and--
I cannot be arsed
I can see that.
The system's not perfect, but that doesn't translate into:
@flabdablet said in Powershell by default:
this entire mechanism is completely and utterly pointless.
@flabdablet said in Powershell by default:
What they have done does not make PowerShell in any way secure. It just makes it less convenient for no security gain whatsoever.
That's all I'm saying. Cripes.
-
@heterodox said in Powershell by default:
That's not an argument about PowerShell
Sure it is. The .cmd wrapper is a convenience only. If PowerShell's executionpolicy setting was something that required elevation or group policy to alter, and was not trivially overridable with the -executionpolicy command line switch and completely ignored by the -command command line switch, so that a site admin could actually prevent unsigned PowerShell scripts from executing on their box, then the trivial wrapping of a .ps1 script in .cmd clothing would not completely burn its security model.
If I were in charge of that aspect of the design I would have made .ps1 scripts run on double-click by default on machines not joined to a domain, and signed scripts traceable to a recognized CA run by default on domain machines, and given administrators an actually effective mechanism to lock them down. That's the right balance between usability and security for a new scripting language.
-
@flabdablet said in Powershell by default:
It doesn't actually stop anything bad from happening so it might as well not be there.
That sums up the slippery slope argument that I think is pretty stupid, but if you don't agree I don't think I'm going to get you to see it. "Why introduce stack guard for buffer overflows? You can still heap spray. Why introduce the NX bit? You can still ROP/return to libc. Why introduce ASLR? You can still reduce entropy/try to find gadgets in the process."
Because a dedicated attacker with infinite resources will always make it, but we want to make it as hard as possible and minimize damage. Here's your perfect security framework: 1. Do not own a computer, 2. Do not power it on, and 3. Do not use it. If people like you had their way, we'd have no security at all because security is just inconvenient.
-
@heterodox said in Powershell by default:
If people like you had their way, we'd have no security at all because security is just inconvenient.
That's just completely rank bullshit. If people like me had our way, products claiming to offer security features would actually do so.
-
@heterodox said in Powershell by default:
Here's your perfect security framework: 1. Do not own a computer, 2. Do not power it on, and 3. Do not use it.
that's not perfect security.
If anyone, including yourself, has access to sensitive information that information is not perfectly secure. This includes information that is only in your brain.
Security is about MANAGING risks and BALANCING that against the need to effectively USE the sensitive information.
-
-
@PleegWat said in Powershell by default:
@accalia said in Powershell by default:
This includes information that is only in your brain.
see?
-
@accalia And if you decide to try destroying the key you're probably in for a couple months jail time. Couple years if it's a terrorism accusation.
-
@PleegWat said in Powershell by default:
@accalia And if you decide to try destroying the key you're probably in for a couple months jail time. Couple years if it's a terrorism accusation.
i can't destroy the key if there never was a key to destroy.
-
@accalia said in Powershell by default:
that's not perfect security.
Fine. To be fair and give credit where it's due, Robert Morris correctly stated those rules as the three golden rules of computer security. :P
-
@anonymous234 said in Powershell by default:
@izzion said in Powershell by default:
Valid point, I guess. I also leave my car doors unlocked with the keys in the ignition, since there are plenty of other ways to steal my car anyway.
No, an equivalent metaphor would be to have a house and put iron bars only on the bathroom window in the second floor, for security.
Hey, that's where I have my barred window!
