September 9, 2009 at 11:04 am
Steve Jones - Editor (9/9/2009)
The bigger worry, for me, is that someone's SQL auth pwd is likely their password elsewhere. Lots of people use the same password at work, for their Windows login, at their bank site, etc.
Well, that can be dealt with on the admin level by either requiring an odd combo of characters (usually your password for bank or other personal use will not include special characters) or requiring periodic change of passwords, plus preventing reuse of a prior password for x number of times.
September 9, 2009 at 11:20 am
jpowers (9/9/2009)
Steve Jones - Editor (9/9/2009)
The bigger worry, for me, is that someone's SQL auth pwd is likely their password elsewhere. Lots of people use the same password at work, for their Windows login, at their bank site, etc.Well, that can be dealt with on the admin level by either requiring an odd combo of characters (usually your password for bank or other personal use will not include special characters) or requiring periodic change of passwords, plus preventing reuse of a prior password for x number of times.
Oh joy. I love those kind of passwords. The type I can't memorize but have to write down somewhere. Oh wait, that would be a security violation:-P
September 9, 2009 at 11:30 am
Has anyone actual verified that you can read the plain text passwords in memory? I've looked that the DBCC commands like INPUTBUFFER and OUTPUTBUFFER but can't seem to see how this is done.
Rudy
September 9, 2009 at 11:36 am
Darren,
hadn't thought of that, but that's scary.
September 9, 2009 at 12:03 pm
Clear text version of encrypted passwords in memory? This is the kind of things black hats dream of. Stop thinking of it in terms of a users password and start thinking of it in terms of your password and your sa password.
This should not be occurring, nor should we be relying on 3rd party memory access to correct it. I have no doubt they are professional and careful but I prefer the the software designer to make these changes with the full application and architecture view in mind.
Anyone plan on sending a memory dump off to a 3rd party for debugging analysis with this in mind? If you do, would you care to answer to the C suite on that with full disclosure of this issue?
September 9, 2009 at 1:09 pm
I am much more concerned that this now makes TWO releases from Microsoft in less than a month that require some third party program to "fix" something that never should have gone out of the door in Redmond. Why have we all just become so "accepting" of this? (For those not aware, the recent VS 2008 update "kills" Winzip, and messes up most non-MS installer programs - and now this problem with SQL Server)...
Is it that we are all just beholden to Microsoft and it's increasing lack of good QA on its own products?
In a nutshell, Yes.
As for passwords - one note only... I worked for IBM for years where we were required every 90 days to change passwords. This was called "a good idea" to bring us "increased security". But no one could remember the ever-changing passwords so what high-tech device helped us?
The world famous yellow sticky... And with it, passwords were posted in every cubicle where they were easy to read, copy, and then use as anyone wished. And you didnt need any third party program.... Just eyeballs.
September 9, 2009 at 2:04 pm
rja.carnegie (9/9/2009)
Of course an admin is receiving considerable trust anyway. But giving them possession of all other users' passwords is something else again. As you say, they can impersonate the finance officer and get the server upgrade that was rejected last month... it's for the company's good really, isn't it?I mean, have I got this wrong: I can change your password to what I want it to be. But I can't change it back, or can I? Someone will know I've been fiddling.
My organisation has mixed clients, not all running Windows. We develop in Java. Two ways for Microsoft to be very unhappy with us, so I'm not sure why we even picked their SQL Server. They'd love to say "Sorry - you can only use SQL Server with Windows clients now!" (But our desktop application doesn't get a connection to SQL Server, we're 3-tier. I think we still pay Microsoft for each user, Windows or not...)
If Microsoft starts making umbrellas then it'll be compulsory for new PCs to have an open wire mesh topside. Yeah, laptops too. Sure, they'll dress it up with talk about low-CO2 fanless cooling...
Back up master.
Change the CFO's password, log in as him, make the data changes you want.
Restore master.
Do it during off-hours while the CFO is sleeping, and nobody is likely to notice or know anything.
If you can't trust your DBA to avoid doing that kind of thing, then you need a new DBA.
All that is assuming that audit trails will catch use of Execute As, or SetUser. If they won't catch that, then you don't even have to change his password to execute as him.
All of this assumes, of course, that the CFO has an SQL login instead of using domain authentication. Since that's a dumb idea anyway, I sincerely hope it won't come up for anyone. Ever.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
September 9, 2009 at 5:24 pm
That's the last straw. Plain text passwords stored in memory...what an atrocity! That's it; I'm getting rid of all my software and going back to paper files secured with armed guards.
I'm with Steve - let's get a grip here people.
James Stover, McDBA
September 9, 2009 at 5:45 pm
Although it does sound a little sloppy in the not clearing of memory once the process has finished using the password, I don't think it is that much of an issue. The person gaining this info is already ON the server in some fashion and has high enough access to do anything they want at any rate (sse previous posts about lateral ways in which to fake another users access).
And I wouldnt be waving the hate MS stick either, they arent the only ones to do things in clear text.
You want a really bad one? ATM's (Cash Machines, Hole in the Wall's, etc) have no encryption INSIDE the box.
i.e. the data on your magnetic strip is encrypted, the data being sent/received to your bank is encrypted (hopefully), all processing of the data by the ATM software is clear text.
In recent months quite a lot of ATM's in Europe had been compromised and were storing and then spitting out card/PIN details.
So to me it sounds more an issue with developer culture than any specific vendor.
September 10, 2009 at 3:30 am
My understanding is that the 'Administrator' in question is a member of the Windows local Administrators group, not a SQL Sysadmin. This means the list of people who could exploit this security hole are increased.
Anywhere that holds a cleartext password is a breach of security. This is definitely a problem that Microsoft should fix, rather than saying they don't think many people could exploit the flaw. Now that the flaw is known, there are a number of people in the world who will make it their business to exploit the flaw.
We have also seen the comment that sending a diagnostic dump to a thirdf party (Microsoft or other vendor) would expose your password to an unknown number of people, but who would get the blame if any of those exploited their knowledge to do something using your cerdentials?
On the other hand, knowing that your password is published in cleartext could be a plank in your defense - the litigant would have to prove that no-one else could have exploited this information rather than relying that only you should know your password.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
September 10, 2009 at 6:14 am
If your business is large enough, and bound by some set of standards such as PCI, then storing passwords in clear text is a very big deal.
Not that I think it is easily manipulated, but sometimes the *appearance* of a vulnerability is actually worse the vulnerability itself. Needs to be fixed, and as a DBA, I would apply whatever patches necessary (on certain systems).
September 15, 2009 at 11:24 am
Rudy Panigas (9/9/2009)
Has anyone actual verified that you can read the plain text passwords in memory? I've looked that the DBCC commands like INPUTBUFFER and OUTPUTBUFFER but can't seem to see how this is done.
Have to assume it's real - think DBCC BYTES might be the way?
September 15, 2009 at 12:09 pm
Thanks for the info SuperDBA. After looking at DBCC BYTES is seems to me that knowing the actual address for the login account is not easily done. Do you think that the location is the same on all SQL server and if so where would you find the starting address.
Many thanks,
Rudy
Rudy
September 16, 2009 at 8:03 am
You could reverse engineer the fix, unless it cleans RAM indiscriminately, not only where the password is lying. Or try DBCC CLEARTEXTPASSWORD or DBCC PASSWORD('user') WITH NO_HASH. 🙂
Viewing 14 posts - 16 through 28 (of 28 total)
You must be logged in to reply to this topic. Login to reply