9

In SQL Server 2008 R2, I got several deadlock reports that have "*password------------" in the input buffer. It looks like an attack but in that case I don't know the reason or the kind of attack.

(the log was generated by an expert DBA how has lot of experience and told me that, not me)

Does anyone know what it is? Thanks!

Example:

<?xml version="1.0"?>
<blocked-process>
  <process id="process879948" taskpriority="0" logused="0" waitresource="KEY: 5:72057602473263104 (1d69201d0ba6)" waittime="5185" ownerId="88389135" transactionname="SELECT" lasttranstarted="2012-09-25T18:11:02.507" XDES="0x1f7d2a590" lockMode="S" schedulerid="2" kpid="4552" status="suspended" spid="86" sbid="2" ecid="0" priority="0" trancount="0" lastbatchstarted="2012-09-25T18:11:02.507" lastbatchcompleted="2012-09-25T18:11:02.507" lastattention="2012-09-25T18:07:35.740" clientapp=".Net SqlClient Data Provider" hostname="IP-xxxxxxxx" hostpid="4868" loginname="sa" isolationlevel="read committed (2)" xactid="88389135" currentdb="1" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128056">
    <executionStack>
      <frame line="14" stmtstart="374" stmtend="764" sqlhandle="0x03000500dac2967f208e4000a19d00000000000000000000"/>
      <frame line="1" stmtstart="44" sqlhandle="0x02000000632f7e131f79ec7312284505961e537a61b81be7"/>
      <frame line="1" sqlhandle="0x000000000000000000000000000000000000000000000000"/>
    </executionStack>
    <inputbuf>

*password---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------   </inputbuf>
  </process>
</blocked-process>
Improve this question

1 Answer 1

Reset to default
11

It just means that the text of the statement contained the string "password" and SQL Server "helpfully" has masked it as a security feature to prevent you seeing some one else's password.

I was able to reproduce this as follows

CREATE TABLE T(X varchar(1000))

Connection 1

BEGIN TRAN

INSERT INTO T VALUES('password1') 

WAITFOR DELAY '00:01:00'

SELECT * FROM T WHERE X = 'password2'

ROLLBACK

Connection 2

BEGIN TRAN

INSERT INTO T VALUES('password2') 

WAITFOR DELAY '00:01:00'

SELECT * FROM T WHERE X = 'password1'

ROLLBACK

Then retrieving the graph from the extended events trace

Improve this answer
5
  • 2
    @DiegoJancic - As for whether this is an attack or not it depends if you expect legitimate queries to contain this string or not. If you don't have any object names containing this string then maybe it could indicate a SQL injection attempt.
    – Martin Smith
    Commented Sep 28, 2012 at 14:48
  • Thanks @MartinSmith, in my case it's not attack, I have a users table with a password field. Thanks again! =)
    – Diego Jancic
    Commented Sep 28, 2012 at 14:51
  • Is there a way to disable this feature?
    – jlb
    Commented Oct 11, 2016 at 14:59
  • 1
    @jlb - Not that I'm aware of. You could raise a request here connect.microsoft.com/SQLServer/Feedback and maybe you'll find out there is some way though.
    – Martin Smith
    Commented Oct 11, 2016 at 15:09
  • @MartinSmith Have asked in the MSDN forums and all replies indicate that there's no way to disable this functionality.
    – jlb
    Commented Oct 12, 2016 at 6:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.