Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: [Full-disclosure] Google Talk cleartext credentials in processmemory |
|---|---|
| Date: | Tue, 29 Nov 2005 19:51:43 -0800 |
Kurt Grutzmacher wrote:
Just stop keeping our secrets laying around in the "open." That's all we ask.
In my opinion this is not a very effective thing to rally against. The operating system already presents a means to protect against one process snooping on the other, as has already been pointed out elsewhere in this thread. If this sort of attack is a concern then you should be urging the user to not run as administrator. There are a number of resources on how to do this, it is far from impossible: <http://nonadmin.editme.com/> and <http://blogs.msdn.com/aaron%5Fmargosis/> are two. The fact is that if you get to the point where you A) can run code on the target's computer and B) that code has sufficient privileges to read another process's memory, then you've already lost, it's too late. Trying to mitigate things at that point is just re-arranging deckchairs. Even if the target program scrambles the password in memory, it by definition has to use the password in cleartext at some point (otherwise it would have no need for it in the first place) and so the attacking program could use a number of methods (like dicking around with process or thread priorities to create a race condition, using the debug API, using the hooks API, intercepting window messages, etc) to read the process's memory at the moment that it had the password in cleartext. As you yourself point out, there are a very large number of programs that don't bother to try to obfuscate cleartext secrets in their own process memory, because they realize it's just not their problem to deal with. Fixing all of them would be nearly impossible. From a cost/benefit analysis, which is more effective: Using the operating system's built-in protection which works for all processes, or trying to convince every Tom, Dick, and Harry that has ever written a throwaway shareware app that they need to make some change? It's whack-a-mole. Brian _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
| Previous by Date: | [Full-disclosure] SOX whistleblowers' clause Compliance, Aditya Deshmukh |
|---|---|
| Next by Date: | Re: [Full-disclosure] SOX whistleblowers' clause Compliance, InfoSecBOFH |
| Previous by Thread: | Re: [Full-disclosure] Google Talk cleartext credentials in process memory, Kurt Grutzmacher |
| Next by Thread: | Re: [Full-disclosure] Google Talk cleartext credentials in processmemory, Kurt Grutzmacher |
| Indexes: | [Date] [Thread] [Top] [All Lists] |