Post reply

How to modify $pshome PowerShell 2.0 variable so that it points to a different directory

  • January 25, 2012 at 6:17 pm

    #1438519

    babatmanpub (1/25/2012)

    Just for those who would like to change $pshome : you can do it here :

    with regedit

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\PSConfigurationProviders\Microsoft.PowerShell]

    "ApplicationBase"="c:\\Windows\\System32\\WindowsPowerShell\\v1.0"

    Nicely done.

    Shifting gears a bit (and no implications about the code above... it just reminded me), one of the ways hackers can execute DOS commands on a system where xp_CmdShell has been not only disabled (the default on 2k5 and above), but the related DLL has been either renamed, unregistered, or even deleted, is to poke a certain value into the registry and use OPENROWSET to issue a DOS command.

    And, no... sorry... not going to show folks how to do that. They just need to be aware that it can be done very easily so they understand that you really need to be care about the level of privs you give to application code.

    --Jeff Moden

    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • January 26, 2012 at 1:54 am

    #1438612

    Jeff Moden (1/25/2012)

    babatmanpub (1/25/2012)

    Just for those who would like to change $pshome : you can do it here :

    with regedit

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\PSConfigurationProviders\Microsoft.PowerShell]

    "ApplicationBase"="c:\\Windows\\System32\\WindowsPowerShell\\v1.0"

    Nicely done.

    Shifting gears a bit (and no implications about the code above... it just reminded me), one of the ways hackers can execute DOS commands on a system where xp_CmdShell has been not only disabled (the default on 2k5 and above), but the related DLL has been either renamed, unregistered, or even deleted, is to poke a certain value into the registry and use OPENROWSET to issue a DOS command.

    And, no... sorry... not going to show folks how to do that. They just need to be aware that it can be done very easily so they understand that you really need to be care about the level of privs you give to application code.

    Whilst I am ever so curious, I applaud your decision NOT to share that in this forum. If only one person applied that technique then it would have been one too many. Good of you to show such restraint online when there is always the temptation to demonstrate how knowledgable one is 😉

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • January 26, 2012 at 7:04 am

    #1438754

    Jeff Moden (8/16/2011)

    I know it doesn't help but this is one of the many reasons why I try to do as much as possible from T-SQL. 😉

    The environmental oddities introduced while developing in a managed virtual workstation environment is on your list of reasons why not to use PowerShell? Hmmm, OK.

    For the environment described, the use of PowerShell is a great choice given how it can seamlessly marry the Windows and SQL programming domains without going through xp_cmdshell to get to a Windows programming domain. Further to that, with xp_cmdshell disabled, a proper system config IMHO, it pre-emptively addresses any inklings of turning the machine hosting SQL Server into a full-fledged application server.

    There are no special teachers of virtue, because virtue is taught by the whole community.
    --Plato

  • January 26, 2012 at 7:09 am

    #1438757

    Jeff Moden (1/25/2012)

    babatmanpub (1/25/2012)

    Just for those who would like to change $pshome : you can do it here :

    with regedit

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\PSConfigurationProviders\Microsoft.PowerShell]

    "ApplicationBase"="c:\\Windows\\System32\\WindowsPowerShell\\v1.0"

    Nicely done.

    Shifting gears a bit (and no implications about the code above... it just reminded me), one of the ways hackers can execute DOS commands on a system where xp_CmdShell has been not only disabled (the default on 2k5 and above), but the related DLL has been either renamed, unregistered, or even deleted, is to poke a certain value into the registry and use OPENROWSET to issue a DOS command.

    And, no... sorry... not going to show folks how to do that. They just need to be aware that it can be done very easily so they understand that you really need to be care about the level of privs you give to application code.

    The issue you describe, and potentially others like it, is likely why OPENROWSET, in additon to xp_cmdshell, have been disabled by default since SQL Server 2005.

    There are no special teachers of virtue, because virtue is taught by the whole community.
    --Plato

  • January 26, 2012 at 8:40 am

    #1438851

    opc.three (1/26/2012)

    Jeff Moden (1/25/2012)

    babatmanpub (1/25/2012)

    Just for those who would like to change $pshome : you can do it here :

    with regedit

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\PSConfigurationProviders\Microsoft.PowerShell]

    "ApplicationBase"="c:\\Windows\\System32\\WindowsPowerShell\\v1.0"

    Nicely done.

    Shifting gears a bit (and no implications about the code above... it just reminded me), one of the ways hackers can execute DOS commands on a system where xp_CmdShell has been not only disabled (the default on 2k5 and above), but the related DLL has been either renamed, unregistered, or even deleted, is to poke a certain value into the registry and use OPENROWSET to issue a DOS command.

    And, no... sorry... not going to show folks how to do that. They just need to be aware that it can be done very easily so they understand that you really need to be care about the level of privs you give to application code.

    The issue you describe, and potentially others like it, is likely why OPENROWSET, in additon to xp_cmdshell, have been disabled by default since SQL Server 2005.

    Yep... I understand that. But disabling these features is of no use if someone hacks in with "SA" privs which is why user and application logins should never have such privs.

    --Jeff Moden

    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • January 26, 2012 at 9:28 am

    #1438890

    Jeff Moden (1/26/2012)

    Yep... I understand that. But disabling these features is of no use if someone hacks in with "SA" privs which is why user and application logins should never have such privs.

    No arguments there. Securing sa should be a top priority for everyone. Sadly I see applications logging in as sa all too often. Disabling the sa account is on my todo list when provisioning new instances. When evaluating current state on inherited instances the sa login is checked as are all fixed server roles (esp. sysadmin, securityadmin and serveradmin) to see who can do what at the server level. If I have my druthers I will run the instance in Windows Authentication mode.

    There are no special teachers of virtue, because virtue is taught by the whole community.
    --Plato

Viewing 6 posts - 16 through 20 (of 20 total)

You must be logged in to reply to this topic. Login to reply