My laptop Lenovo ThinkPad needs to support Virtualization ASAP

This post was originally published on this site

Greetings all,

 

I seek your prompt support to help me resolve my virtualization issue as my laptop ThinkPad X series apparently doesn’t support the Virtualization.

I badly need my computer to support the virtualization as I will have a training course next week. Please note that I could follow this step: How to enable Virtualization Technology (VT-X) in Lenovo, idea, ThinkPad and ThinkCentre system – sa ; however, it seems that my laptop still doesn’t support it. If you also can provide me with a tool to check or find out whether my laptop supports the virtualization after following the instruction through the abovementioned link or not.

 

This info may be helpful:

 

Processor:”Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz , GenuineIntel”

Windows 10.

 

 

Any ideas to resolve this issue ASAP would be really much appreciated.

 

Best,

AAA

___VMware_Conv_SA___

This post was originally published on this site

Hey there.

 

After i’ve installed Vmware converter all, in my laptop probook 640g2, it blocked because the vmware created user ___VMware_Conv_SA___ and this user conflicted with the HP software security and blocked my bios.

 

Now… when i try to start my laptop, the pasword for user ___VMware_Conv_SA___ is requested.

 

I would like any assistance for know the password of user for unlock my probook bios.

 

Regards

 

Rafael

PowerShell Module Function Export in Constrained Language

This post was originally published on this site

PowerShell Module Exporting Functions in Constrained Language

PowerShell offers a number of ways to expose functions in a script module. But some options have serious performance or security drawbacks. In this blog I describe these issues and provide simple guidance for creating performant and secure script modules. Look for a module soon in PSGallery that helps you update your modules to be compliant with this guidance.

When PowerShell is running in Constrained Language mode it adds some restrictions in how module functions can be exported. Normally, when PowerShell is not running in Constrained Language, all script functions defined in the module are exported by default.

# TestModule.psm1
function F1 { }
function F2 { }
function F3 { }

# TestModule.psd1
@{ ModuleVersion = '1.0'; RootModule = 'TestModule.psm1' }

# All functions (Function1, Function2, Function3) are exported and available
Get-Module -Name TestModule -List | Select -ExpandProperty ExportedFunctions

F1
F2
F3

This is handy and works well for simple modules. However, it can cause problems for more complex modules.

Performance Degradation

Command discovery is much slower when script functions are exported implicitly or explicitly using wildcard characters. This is because PowerShell has to parse all module script content to look for available functions and then match the found function names with a wildcard pattern. If the module uses explicit function export lists, then this parsing during discovery is not necessary. If you have a lot of custom script modules with many functions, the performance hit can become very noticeable. This principal also applies to exporting any other script element such as cmdlets, variables, aliases, and DSC resources.

# TestModule.psm1
function F1 { }
function F2 { }
function F3 { }
...
# This wildcard function export has the same behavior as the default behavior, all module functions are exported and PowerShell has to parse all script to discover available functions
Export-ModuleMember -Function '*'

Confused Intent

For large complex modules, exporting all defined functions is confusing to users as to how the module is intended to be used. The number of defined functions can be very large and the handful of user cmdlets can get lost in the noise. It is much better to export just the functions intended for the user and hide all helper functions.

# TestModule.psm1
function Invoke-Program { }
function F1 { }
function F2 { }
...
function F100 { }

# TestModule.psd1
@{ ModuleVersion = '1.0'; RootModule = 'TestModule.psm1'; FunctionsToExport = 'Invoke-Program' }

Get-Module -Name TestModule -List | Select -ExpandProperty ExportedFunctions

Invoke-Program

Security

PowerShell runs in Constrained Language mode when a DeviceGuard or AppLocker policy is enforced on the system. This provides a good user shell experience while allowing trusted script modules to run in Full Language so that system management can still be done. For example, a user from the command line cannot use Add-Type to create and run arbitrary C# types, but a trusted script can.

So, it is important that a trusted script does not expose any vulnerabilities such as script injection or arbitrary code execution. Another type of vulnerability is leaking dangerous module functions not intended for public use. A helper function might take arbitrary source code and create a type intended to be used privately in a trusted context. But, if that helper function becomes publically available it exposes a code execution vulnerability.

# TestModule.psm1
function Invoke-Program { }
# Private helper function
function Get-Type
{
    param( [string] $source )
    Add-Type -TypeDefinition $source -PassThru
}

# Exposes *all* module functions!
Export-ModuleMember -Function '*'

Get-Module -Name TestModule -List | Select -ExpandProperty ExportedFunctions

Invoke-Program
Get-Type

In the above example, Get-Type module helper function is exported via wildcard along with the intended Invoke-Program function. Since this is a trusted module Get-Type runs in Full Language and exposes the ability to create arbitrary types.

Unintended Consequences

A major problem with exporting module functions using wildcards is that you may end up exporting functions unintentionally. For example, your module may specify other nested modules, or it may explicitly import other modules, or it may dot source script files into the module scope. All of those script functions will become publicly available if wild cards are used to export module functions.

# TestModule.psm1
import-Module HelperMod1
. .CSharpHelpers.ps1
function Invoke-Program { }

# Exposes *all* module functions!
Export-ModuleMember -Function '*'

Get-Module -Name TestModule -List | Select -ExpandProperty ExportedFunctions
Invoke-Program
HelperFn1
HelperFn2
Compile-CSharp

Module Function Export Restrictions

When PowerShell detects that an application whitelisting policy is enforced it runs in Constrained Language mode as mentioned previously, but it also applies some function export restrictions for imported modules. Remember that these restrictions only apply when PowerShell is running under DeviceGuard or AppLocker policy enforcement mode. Otherwise module function export works as before.

  • Wildcards are not allowed with the FunctionsToExport keyword in a module manifest (.psd1 file). If a wildcard is found in the keyword argument then no functions are exported in that module.
  • Wildcards are allowed in a module script file (.psm1). This is to provide backward compatibility but we strongly discourage it.
  • A module that uses wildcards to export functions, and at the same time dot sources script files into the module scope, will throw an error during module loading time. Note that if a psm1 file exports functions via wildcard, but it is imported under a manifest (psd1 file) that exports functions explicitly by name, then no error is thrown because the psd1 overrides any function export done within a psm1 file associated with the manifest. But if the psm1 file is imported directly (without the psd1 manifest file) then the error is thrown (see example below). Basically, the dot source operator cannot be used in module script along with wildcard based function export. It is too easy to inadvertently expose unwanted functions.

These restrictions are to help prevent inadvertent exposure of functions. By using wildcard based function export, you may be exposing dangerous functions without knowing it.

# TestModule.psm1
Import-Module HelperMod1
. .CSharpHelpers.ps1
function Invoke-Program { }
Export-ModuleMember -Function '*'

# TestModule.psd1
@{ ModuleVersion='1.0'; RootModule='TestModule.psm1'; FunctionsToExport='Invoke-Program' }

# Importing the psm1 file directly results in error because of the wildcard function export and use of dot source operator
Import-Module -Name TestModuleTestModule.psm1
Error:
'This module uses the dot-source operator while exporting functions using wildcard characters, and this is disallowed when the system is under application verification enforcement.'

# But importing using the module manifest succeeds since the manifest explicitly exports functions by name without wildcards
Import-Module TestModule
Get-Module -Name TestModule | Select -ExpandProperty ExportedFunctions
Invoke-Program

Module Function Export Best Practices

Best practices for module function exporting is pretty simple. Always export module functions explicitly by name. Never export using wild card names. This will yield the best performance and ensure you don’t expose functions you don’t intend to expose. It makes your module safer to use as trusted in a DeviceGuard policy enforcement environment.

# TestModule.psm1
Import-Module HelperMod1
. .CSharpHelpers.ps1
function Invoke-Program { }

# TestModule.psd1
@ { ModuleVersion='1.0'; RootModule='TestModule.psm1'; FunctionsToExport='Invoke-Program' }

Get-Module -Name TestModule -List | Select -ExpandProperty ExportedFunctions
Invoke-Program

Paul Higinbotham
Senior Software Engineer
PowerShell Team

PowerShell Module Exporting Functions in Constrained Language

This post was originally published on this site

PowerShell Module Exporting Functions in Constrained Language

PowerShell offers a number of ways to expose functions in a script module. But some options have serious performance or security drawbacks. In this blog I describe these issues and provide simple guidance for creating performant and secure script modules. Look for a module soon in PSGallery that helps you update your modules to be compliant with this guidance.

When PowerShell is running in Constrained Language mode it adds some restrictions in how module functions can be exported. Normally, when PowerShell is not running in Constrained Language, all script functions defined in the module are exported by default.

# TestModule.psm1
function F1 { }
function F2 { }
function F3 { }

# TestModule.psd1
@{ ModuleVersion = '1.0'; RootModule = 'TestModule.psm1' }

# All functions (Function1, Function2, Function3) are exported and available
Get-Module -Name TestModule -List | Select -ExpandProperty ExportedFunctions

F1
F2
F3

This is handy and works well for simple modules. However, it can cause problems for more complex modules.

Performance Degradation

Command discovery is much slower when script functions are exported implicitly or explicitly using wildcard characters. This is because PowerShell has to parse all module script content to look for available functions and then match the found function names with a wildcard pattern. If the module uses explicit function export lists, then this parsing during discovery is not necessary. If you have a lot of custom script modules with many functions, the performance hit can become very noticeable. This principal also applies to exporting any other script element such as cmdlets, variables, aliases, and DSC resources.

# TestModule.psm1
function F1 { }
function F2 { }
function F3 { }
...
# This wildcard function export has the same behavior as the default behavior, all module functions are exported and PowerShell has to parse all script to discover available functions
Export-ModuleMember -Function '*'

Confused Intent

For large complex modules, exporting all defined functions is confusing to users as to how the module is intended to be used. The number of defined functions can be very large and the handful of user cmdlets can get lost in the noise. It is much better to export just the functions intended for the user and hide all helper functions.

# TestModule.psm1
function Invoke-Program { }
function F1 { }
function F2 { }
...
function F100 { }

# TestModule.psd1
@{ ModuleVersion = '1.0'; RootModule = 'TestModule.psm1'; FunctionsToExport = 'Invoke-Program' }

Get-Module -Name TestModule -List | Select -ExpandProperty ExportedFunctions

Invoke-Program

Security

PowerShell runs in Constrained Language mode when a DeviceGuard or AppLocker policy is enforced on the system. This provides a good user shell experience while allowing trusted script modules to run in Full Language so that system management can still be done. For example, a user from the command line cannot use Add-Type to create and run arbitrary C# types, but a trusted script can.

So, it is important that a trusted script does not expose any vulnerabilities such as script injection or arbitrary code execution. Another type of vulnerability is leaking dangerous module functions not intended for public use. A helper function might take arbitrary source code and create a type intended to be used privately in a trusted context. But, if that helper function becomes publically available it exposes a code execution vulnerability.

# TestModule.psm1
function Invoke-Program { }
# Private helper function
function Get-Type
{
    param( [string] $source )
    Add-Type -TypeDefinition $source -PassThru
}

# Exposes *all* module functions!
Export-ModuleMember -Function '*'

Get-Module -Name TestModule -List | Select -ExpandProperty ExportedFunctions

Invoke-Program
Get-Type

In the above example, Get-Type module helper function is exported via wildcard along with the intended Invoke-Program function. Since this is a trusted module Get-Type runs in Full Language and exposes the ability to create arbitrary types.

Unintended Consequences

A major problem with exporting module functions using wildcards is that you may end up exporting functions unintentionally. For example, your module may specify other nested modules, or it may explicitly import other modules, or it may dot source script files into the module scope. All of those script functions will become publicly available if wild cards are used to export module functions.

# TestModule.psm1
import-Module HelperMod1
. .CSharpHelpers.ps1
function Invoke-Program { }

# Exposes *all* module functions!
Export-ModuleMember -Function '*'

Get-Module -Name TestModule -List | Select -ExpandProperty ExportedFunctions
Invoke-Program
HelperFn1
HelperFn2
Compile-CSharp

Module Function Export Restrictions

When PowerShell detects that an application whitelisting policy is enforced it runs in Constrained Language mode as mentioned previously, but it also applies some function export restrictions for imported modules. Remember that these restrictions only apply when PowerShell is running under DeviceGuard or AppLocker policy enforcement mode. Otherwise module function export works as before.

  • Wildcards are not allowed with the FunctionsToExport keyword in a module manifest (.psd1 file). If a wildcard is found in the keyword argument then no functions are exported in that module.
  • Wildcards are allowed in a module script file (.psm1). This is to provide backward compatibility but we strongly discourage it.
  • A module that uses wildcards to export functions, and at the same time dot sources script files into the module scope, will throw an error during module loading time. Note that if a psm1 file exports functions via wildcard, but it is imported under a manifest (psd1 file) that exports functions explicitly by name, then no error is thrown because the psd1 overrides any function export done within a psm1 file associated with the manifest. But if the psm1 file is imported directly (without the psd1 manifest file) then the error is thrown (see example below). Basically, the dot source operator cannot be used in module script along with wildcard based function export. It is too easy to inadvertently expose unwanted functions.

These restrictions are to help prevent inadvertent exposure of functions. By using wildcard based function export, you may be exposing dangerous functions without knowing it.

# TestModule.psm1
Import-Module HelperMod1
. .CSharpHelpers.ps1
function Invoke-Program { }
Export-ModuleMember -Function '*'

# TestModule.psd1
@{ ModuleVersion='1.0'; RootModule='TestModule.psm1'; FunctionsToExport='Invoke-Program' }

# Importing the psm1 file directly results in error because of the wildcard function export and use of dot source operator
Import-Module -Name TestModuleTestModule.psm1
Error:
'This module uses the dot-source operator while exporting functions using wildcard characters, and this is disallowed when the system is under application verification enforcement.'

# But importing using the module manifest succeeds since the manifest explicitly exports functions by name without wildcards
Import-Module TestModule
Get-Module -Name TestModule | Select -ExpandProperty ExportedFunctions
Invoke-Program

Module Function Export Best Practices

Best practices for module function exporting is pretty simple. Always export module functions explicitly by name. Never export using wild card names. This will yield the best performance and ensure you don’t expose functions you don’t intend to expose. It makes your module safer to use as trusted in a DeviceGuard policy enforcement environment.

# TestModule.psm1
Import-Module HelperMod1
. .CSharpHelpers.ps1
function Invoke-Program { }

# TestModule.psd1
@ { ModuleVersion='1.0'; RootModule='TestModule.psm1'; FunctionsToExport='Invoke-Program' }

Get-Module -Name TestModule -List | Select -ExpandProperty ExportedFunctions
Invoke-Program

Paul Higinbotham
Senior Software Engineer
PowerShell Team

HPe Gen10 DL360 servers networking failing

This post was originally published on this site

We have 4 new DL360’s GEN10, and we’re having issues with the switch ARP table not following what the servers have going on, and we’re seeing it seems to be mostly on the 10GBC ports.

 

I’ve ran this up with HPE and Aruba(switch) and they’re pointing at the OS (ESXI 6.5) as being the issue.

 

We have ISCSI and its running on the second SFP+ port going into a separate switch with Nimble storage, thats working great. No issues i’m aware of.

 

The VM’s will randomly drop off, and i’m stuck moving them to 1GB ports, or VMotion to another server. The switch will show all 0’s for a mac, and not list a port, but have the IP in the arp table. This seems to be only happening on the VMS on the new environment, and they all came from a 6.0 version of vmware, and we migrated them over. We haven’t had as many problems on the 1GB ports, but a few other people involved have told me we have. This was running from Friday until this morning with no problems, and today at 8 am it died. We moved the servers onto the 1GB and vmotion to another host and seems to be fine. This randomly happens across all the hosts, and we’ve not found anything to be strange, and the ISCSI doesn’t skip a beat.

 

Suggestions?

PowerShell Standard Library: Build single module that works across Windows PowerShell and PowerShell Core

This post was originally published on this site

This is the first of a series of blog posts that will help you take advantage of a new NuGet package PowerShellStandard Library 5.1.0. This package allows developers to create modules that are portable between Windows PowerShell 5.1 and PowerShell Core 6.0. This means that you can create PowerShell modules that run on Windows, Linux, and macOS with a single binary!

The version of PowerShell Standard Library indicates the lowest version of PowerShell that it is compatible with. The community promise is that it is always forward compatible. So a module built against PowerShell Standard Library v3 is compatible with Windows PowerShell v3, v4, v5.1, PowerShell Core 6, and the upcoming PowerShell Core 6.1. Compatibility is achieved by providing a subset of the APIs common across all those versions of PowerShell. This reference assembly is the equivalent to a header file for C/C++ where it has the APIs defined, but no implementation. During runtime, the module would use the version of System.Management.Automation.dll that is used by the PowerShell host.

Creating a PowerShell Module

In this post, I’ll walk through the steps for creating a simple C# module with a single cmdlet. I will also be using the DotNet CLI tools for creating everything I need.

Installing the PowerShell Standard Module Template

First, we can leverage a new template that we published for DotNet CLI, but we need to install it first:

PS> dotnet new -i Microsoft.PowerShell.Standard.Module.Template
  Restoring packages for C:UsersJames.templateenginedotnetcliv2.1.302scratchrestore.csproj...
  Installing Microsoft.PowerShell.Standard.Module.Template 0.1.3.
  Generating MSBuild file C:UsersJames.templateenginedotnetcliv2.1.302scratchobjrestore.csproj.nuget.g.props.
  Generating MSBuild file C:UsersJames.templateenginedotnetcliv2.1.302scratchobjrestore.csproj.nuget.g.targets.
  Restore completed in 1.66 sec for C:UsersJames.templateenginedotnetcliv2.1.302scratchrestore.csproj.

Usage: new [options]

Options:
  -h, --help          Displays help for this command.
  -l, --list          Lists templates containing the specified name. If no name is specified, lists all templates.
  -n, --name          The name for the output being created. If no name is specified, the name of the current directory is used.
  -o, --output        Location to place the generated output.
  -i, --install       Installs a source or a template pack.
  -u, --uninstall     Uninstalls a source or a template pack.
  --nuget-source      Specifies a NuGet source to use during install.
  --type              Filters templates based on available types. Predefined values are "project", "item" or "other".
  --force             Forces content to be generated even if it would change existing files.
  -lang, --language   Filters templates based on language and specifies the language of the template to create.


Templates                                         Short Name         Language          Tags                             
----------------------------------------------------------------------------------------------------------------------------
Console Application                               console            [C#], F#, VB      Common/Console                   
Class library                                     classlib           [C#], F#, VB      Common/Library                   
PowerShell Standard Module                        psmodule           [C#]              Library/PowerShell/Module    
...

A new template called psmodule is now available making it easy to start a new C# based PowerShell module. Any issues, feedback, or suggestions for this template should be opened in the PowerShell Standard repo.

Creating a new project

We need to create a location for our new project and then use the template to create the project:

PS> mkdir myModule
Directory: C:UsersJames
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 8/3/2018 2:41 PM myModule
PS> cd myModule
PS C:UsersJamesmyModule> dotnet new psmodule
The template "PowerShell Standard Module" was created successfully.

Processing post-creation actions...
Running 'dotnet restore' on C:UsersJamesmyModulemyModule.csproj...
  Restoring packages for C:UsersJamesmyModulemyModule.csproj...
  Installing PowerShellStandard.Library 5.1.0-preview-06.
  Generating MSBuild file C:UsersJamesmyModuleobjmyModule.csproj.nuget.g.props.
  Generating MSBuild file C:UsersJamesmyModuleobjmyModule.csproj.nuget.g.targets.
  Restore completed in 1.76 sec for C:UsersJamesmyModulemyModule.csproj.

Restore succeeded.

You can see that the dotnet cli has created a source file and .csproj file for my project:

PS C:UsersJamesmyModule> dir


    Directory: C:UsersJamesmyModule


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----         8/3/2018   1:48 PM                obj
-a----         8/3/2018   1:48 PM            376 myModule.csproj
-a----         8/3/2018   1:48 PM           1698 TestSampleCmdletCommand.cs

The sample from the template demonstrates a simple cmdlet with two parameters that outputs results with a custom class.

Building the module

Building the sample is code is easy with DotNet CLI:

PS C:UsersJamesmyModule> dotnet build
Microsoft (R) Build Engine version 15.7.179.6572 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Restore completed in 76.85 ms for C:UsersJamesmyModulemyModule.csproj.
  myModule -> C:UsersJamesmyModulebinDebugnetstandard2.0myModule.dll

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:05.40

Testing the built module

To test this sample module, we just need to import it. We can check to see what it supports and try running it:

PS C:UsersJamesmyModule> ipmo .binDebugnetstandard2.0myModule.dll
PS C:UsersJamesmyModule> Test-SampleCmdlet -?

NAME
    Test-SampleCmdlet

SYNTAX
    Test-SampleCmdlet [-FavoriteNumber] <int> [[-FavoritePet] {Cat | Dog | Horse}] [<CommonParameters>]


ALIASES
    None


REMARKS
    None



PS C:UsersJamesmyModule> Test-SampleCmdlet -FavoriteNumber 7 -FavoritePet Cat

FavoriteNumber FavoritePet
-------------- -----------
             7 Cat

This sample is pretty simple as it’s intended to just show how to get started on writing a PowerShell module from scratch. The important point is that using PowerShell Standard Library, this assembly can be used in both PowerShell Core 6 as well as Windows PowerShell. This sample will even work on Windows, Linux, or macOS without any changes.

In the next part of this series, I’ll cover other aspects of PowerShell module authoring such as module manifests and writing Pester tests.

James Truher
Senior Software Engineer
PowerShell Team

PowerShell Injection Hunter: Security Auditing for PowerShell Scripts

This post was originally published on this site

At the DEFCON security conference last year, we presented the session: “Get $pwnd: Attacking Battle Hardened Windows Server“.

In this talk, we went through some of the incredibly powerful ways that administrators can secure their high-value systems (for example, Just Enough Administration) and also dove into some of the mistakes that administrators sometimes make when exposing their their PowerShell code to an attacker. The most common form of mistake is script injection, where a script author takes a parameter value (supplied by an attacker) and runs it in a trusted context (such as a function exposed in a Just Enough Administration endpoint). Here’s an example:

 

There are many coding patterns that can introduce security flaws like this, all of which have secure alternatives. The presentation goes into these in great detail, and what we also promised to release is a tool to help you detect them as you are writing the scripts. We’ve now released this tool, and you can download it from the PowerShell Gallery:

Using it this way from the command line is an excellent way to automate security analysis during builds, continuous integration processes, deployments, and more.

Wouldn’t it be REALLY cool if you could detect these dangers while writing your scripts? I’m glad you asked!

PowerShell’s Visual Studio Code plugin already does live script analysis to help you discover issues like unassigned variables, and we can customize that rule set to include InjectionHunter capabilities. Here’s what Visual Studio Code looks like with this running:

Here’s how to get this on your system:

First, find out the location of the InjectionHunter module. You can do this by typing:

Get-Module InjectionHunter -List | Foreach-Object Path

On my system, this returns:

D:LeeWindowsPowerShellModulesInjectionHunter1.0.0InjectionHunter.psd1

Next, create a file – ‘PSScriptAnalyzerSettings.psd1’ in a location of your choice. Use the following for the content – replacing the path to InjectionHunter with the one on your system.

@{
 IncludeDefaultRules = $true
 CustomRulePath = "D:LeeWindowsPowerShellModulesInjectionHunter1.0.0InjectionHunter.psd1"
}
Finally, update your Visual Studio Code user settings to tell the PowerShell plugin to use your custom settings. You can get to these by typing Control+Comma, or through File | Preferences | Settings.
I’ve got some settings that match my personal preferences already, so the critical line to add is:
"powershell.scriptAnalysis.settingsPath""c:/users/lee/PSScriptAnalyzerSettings.psd1"
Where the path to PSScriptAnalyzerSettings.psd1 is the path that you saved your file earlier. When you open a PowerShell script with possible code injection risks, you should now see Script Analyzer warnings that highlight what they are and how to fix them.
Happy hunting!

6.5 shows warning for hardware

This post was originally published on this site

We’re updating our GEN10 HPe servers and we’re getting errors now.

 

I’ve attached a screen shot, but we’re seeing

 

[device] I/O module 1 ALOM_Link_P4

 

 

This wasn’t here until we did the firmware upgrade on the server, and we had nothing but problems with the old firmware dropping connections to VMs, and causing network hell.

 

We obviously don’t want warnings showing up, suggestions?