Post reply

How to call a batch file to execute from an SP

  • March 24, 2013 at 8:17 pm

    #1600157

    Sergiy (3/24/2013)

    opc.three (3/24/2013)

    The fact is that a system with xp_cmdshell disabled has less security exposures, has less vulnerabilities and is more auditable than a system where it is enabled.

    OK.

    I'm an intruder on your system.

    If I'm connected using non-systemadmin credentials I cannot execute any call to xp_cmdshell anyway, and I cannot get privileges associated with it.

    So, it does not really matter if it's disabled or enabled - I won't be able even to figure out that.

    Now, if I'm connected as a systemadmin. First thing I will do is

    EXEC sp_configure 'xp_cmdshell', 1

    Immediately followed by

    RECONFIGURE WITH OVERRIDE

    Voilà!

    xp_cmdshell is enabled, no matter what state it was 3 ms ago.

    So, where those promissed "less security exposures, has less vulnerabilities"?

    You're still hung up on external scenarios.

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

  • March 24, 2013 at 8:19 pm

    #1600158

    Sergiy (3/24/2013)

    opc.three (3/24/2013)

    The point is, xp_cmdshell is a blunt tool that cannot be audited and allows people to run commands as someone else, possibly with more permissions than their own, without the possibility of being detected or tracked.

    Would it be wiser to limit the privileges associated with the account running sqlserver service to its jon related tasks?

    Read from there, write there, check on that location, execute that task.

    That's it. The list is closed.

    If you need to do something else - talk to your system administrator, as they say in MS messages.

    This layer would be definitely harder to pass than to enable xp_cmdshell, don't you think?

    All of those things should be done in addition to leaving xp_cmdshell disabled.

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

  • March 24, 2013 at 8:36 pm

    #1600159

    opc.three (3/24/2013)

    You're still hung up on external scenarios.

    Not really.

    Replace "intruder" with "employee gone nuts".

    What does it change?

    _____________
    Code for TallyGenerator

  • March 24, 2013 at 8:42 pm

    #1600160

    opc.three (3/24/2013)

    All of those things should be done in addition to leaving xp_cmdshell disabled.

    If those things are done there is no point of disabling xp_cmdshell.

    _____________
    Code for TallyGenerator

  • March 24, 2013 at 8:53 pm

    #1600161

    Sergiy (3/24/2013)

    opc.three (3/24/2013)

    You're still hung up on external scenarios.

    Not really.

    Replace "intruder" with "employee gone nuts".

    What does it change?

    Not much you can do there. But consider the employee in the sysadmin Role looking to steal data without being detected. Please re-read earlier posts. Its all laid out there. It depends on what you're protecting against and you're only focusing on the person who blazes in, does damage or steals, and doesn't care much about being detected either because they fade back to the shadows of the internet, or they are a nutso employee who just wants to do damage.

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

  • March 24, 2013 at 8:58 pm

    #1600162

    Sergiy (3/24/2013)

    opc.three (3/24/2013)

    All of those things should be done in addition to leaving xp_cmdshell disabled.

    If those things are done there is no point of disabling xp_cmdshell.

    Why do you need it? There is no need to enable it. What would you need it for if things are locked down to the point where the engine only needs to talk to the file system for writing backups, logs and trace files or other system related operations to allow the instance to function?

    This conversation began discussing cross-server exchanges of data, I.e. Using xp_cmdshell to facilitate an ETL system.

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

  • March 24, 2013 at 9:17 pm

    #1600163

    opc.three (3/24/2013)

    But consider the employee in the sysadmin Role looking to steal data without being detected.

    And?

    How adding an "sp_configure" command to a script used for stealing data will help to detect who's behind the SA user?

    _____________
    Code for TallyGenerator

  • March 24, 2013 at 9:27 pm

    #1600164

    Sergiy (3/24/2013)

    opc.three (3/24/2013)

    But consider the employee in the sysadmin Role looking to steal data without being detected.

    And?

    How adding an "sp_configure" command to a script used for stealing data will help to detect who's behind the SA user?

    Version control. Change management processes. Code review. Layers...

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

  • March 24, 2013 at 10:32 pm

    #1600170

    opc.three (3/24/2013)

    Sergiy (3/24/2013)

    Version control. Change management processes. Code review. Layers...

    What all these words have to do with stealing data by launching an ad-hoc query using SA privilages?

    Or you really believe someone with such intentions would submit such code for peer review before committing???

    :w00t:

    _____________
    Code for TallyGenerator

  • March 25, 2013 at 6:39 am

    #1600278

    Over the years I have isolated xp_cmdshell, xp_sendmail etc from users and 3rd Party applications by using a stored procedure in front of the system procs. All inputs are checked and the made safe and logged.

    Of course another option is to start using assemblies on some of this but then that starts meaning trusted databases and code that cant be read. These are different risk and potentially mopre serious risks.

    It is better to help the developers/3rd Parties to change the code to something safer than just saying no. Minimal change is easier to adapt to then a completely different method accompanied by a steep learning curve

  • March 25, 2013 at 6:48 am

    #1600281

    Sergiy (3/24/2013)

    opc.three (3/24/2013)

    Sergiy (3/24/2013)

    Version control. Change management processes. Code review. Layers...

    What all these words have to do with stealing data by launching an ad-hoc query using SA privilages?

    Or you really believe someone with such intentions would submit such code for peer review before committing???

    :w00t:

    😛 I thought it was a silly comment too, but you said script I went with it.

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

  • March 25, 2013 at 7:08 am

    #1600287

    Sergiy (3/24/2013)

    opc.three (3/24/2013)

    But consider the employee in the sysadmin Role looking to steal data without being detected.

    And?

    How adding an "sp_configure" command to a script used for stealing data will help to detect who's behind the SA user?

    Care to clarify what you meant? Since it is clear now that you did not say "script" to mean something submitted for normal review and deployment.

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

  • March 25, 2013 at 7:07 pm

    #1600571

    opc.three (3/25/2013)

    Care to clarify what you meant? Since it is clear now that you did not say "script" to mean something submitted for normal review and deployment.

    Not sure what needs to be clarified here.

    How do you imagine a process of stealing data?

    I'd see it as someone running a commang against database to retrieve some data and pass it somewhere.

    I would expect it to be an SQL statement, most likely more than 1.

    Which makes it a script.

    http://oxforddictionaries.com/definition/english/script?q=script:

    Definition of script

    noun

    ...

    Computing: an automated series of instructions carried out in a specific order.

    Adding sp_configure command activating xp_cmdshell on top of such script won't create any trouble or hold the process.

    What makes disabling xp_cmdshell absolutely useless.

    _____________
    Code for TallyGenerator

  • March 25, 2013 at 7:41 pm

    #1600572

    opc.three (3/24/2013)

    You're still hung up on 'external attackers.' The point is, xp_cmdshell is a blunt tool that cannot be audited and allows people to run commands as someone else, possibly with more permissions than their own, without the possibility of being detected or tracked. That is not something to be taken lightly and is certainly something most people making decisions about the security of their environment and data would object too if it was fully explained.

    You need to read the question I posed again. I said nothing about 'external attackers'. In fact, I specifically stated that "None of those 'individuals' are actually externally outside SQL server". Here's my post, again.

    Fine. Support your words as I have supported mine. If only few (let's say, 2 DBAs) very trusted individuals have "SA" privs and none of those "individuals" are actually externally outside SQL Server) facing apps (an important point that you've left out that I've emphasized time and again), what kind of problems is having xp_CmdShell turned on going to cause and what kind of problems will be avoided by having it turned off?

    So tell us all, "what kind of problems is having xp_CmdShell turned on going to cause and what kind of problems will be avoided by having it turned off"? If the answer is only "logging", please drive through because an "SA" can do just about anything without it being logged and where it is logged, (s)he can actually delete.

    --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)
    Intro to Tally Tables and Functions

  • March 25, 2013 at 8:01 pm

    #1600576

    Sergiy (3/25/2013)

    opc.three (3/25/2013)

    Care to clarify what you meant? Since it is clear now that you did not say "script" to mean something submitted for normal review and deployment.

    Not sure what needs to be clarified here.

    How do you imagine a process of stealing data?

    I'd see it as someone running a commang against database to retrieve some data and pass it somewhere.

    I would expect it to be an SQL statement, most likely more than 1.

    Which makes it a script.

    http://oxforddictionaries.com/definition/english/script?q=script:

    Definition of script

    noun

    ...

    Computing: an automated series of instructions carried out in a specific order.

    Adding sp_configure command activating xp_cmdshell on top of such script won't create any trouble or hold the process.

    What makes disabling xp_cmdshell absolutely useless.

    Look, you do not need to become a jerk. "Script" is not an unambiguous term in the world of SQL Server. I took it to mean "a saved file submitted by a developer for review by a peer and eventual execution by a DBA."

    The point is, when you run something as xp_cmdshell you are taking on the identity of the SQL Server service account, which in some environments could mean an elevation of your own privileges, e.g. being able to reach file share you yourself could not reach. I am not going to argue with you. It's clear you do not want to see the point, so I cannot do more.

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

Viewing 15 posts - 31 through 45 (of 96 total)

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