[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Credentials held unencrypted in memory during runtime

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Mon, 11 Apr 2011 19:26:39 +0200

On 11.04.2011 19:15, Feldhacker, Chris wrote:
> I would agree that it is a security vulnerability, but, yes, the risk
> is low.

No, it's not. Really.

> It would be a "Sensitive Data Protection Vulnerability"
> https://www.owasp.org/index.php/Category:Sensitive_Data_Protection_Vulnerability
The first example even:
> "Information leakage results from insufficient memory clean-up"

this requires that the information is somehow revealed to the user,
without the user having the privileges to see it (like in an error
message on a website).

> Example of other programs that go to lengths to protect in-memory
> sensitive information: http://keepass.info/features.html

That's for encryption, also not relevant here.

> I read an article a few weeks ago around the time of the RSA incident
> that mentioned the fastest growing threat in recent months is
> actually advanced persistent threats that perform in-memory scraping
> to capture credentials (sorry, can't find the exact link again else
> I'd provide it).
> Yes, if a system is compromised then you've got problems, but that's
> the whole point of a defense-in-depth strategy -- protections in one
> layer or area can help minimize the impact of a breach in another
> area should one occur. Most programming language frameworks or APIs
> return sensitive data in mutable character arrays rather than
> immutable types specifically so the data can be overwritten as soon
> as it's no longer needed to avoid having sensitive data left floating
> around memory...
> FWIW, I'd vote for this bug.

All this issue really is, is that 'security by obscurity' might be
compromised, but that's no security at all.

The user must already have privileges to execute code, otherwise it's
not possible to read process memory.
And if you can execute code, you can just read out *all* passwords from
the encrypted auth file Subversion creates. All you need is the SVN
source code to find out how SVN itself decrypts that file and do the same.
And with that, you have *all* passwords for *all* your repositories, not
just the one currently used in the still running process.

No, this is *not* a security issue. Not at all.


   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2011-04-11 19:26:55 CEST

This is an archived mail posted to the TortoiseSVN Users mailing list.