powered by Jive Software

Mitigating CWE-244 (password readable from memory)

Following CWE - CWE-244: Improper Clearing of Heap Memory Before Release ('Heap Inspection') (4.8) the passwords sent as String object might be a vulnerability as they could possible be read from memory.

While not a high vulnerability, as you’d have to have access to the memory / or leak a memory dump, would it be nice to make the authenticate/login mechanism in Smack use a char array instead?

While not fully mitigating the issue, it does reduce the vulnerability somewhat:

If someone is willing to work on that, then that’s fine, I wouldn’t reject it in general.

That said, I wouldn’t even call it a vulnerability: If someone who is not authorized is able to read your memory, then most bets are off. Also, it is not clear to me what the lifetime scope of the password should be, i.e., when the char array will be overriden and the password destroyed. Most users probably want their XMPP connections to be able to re-authenticate, and this, in absence of something like Instant Stream Resumption, requires the password (and even then you wild need a stronger authentication token, usually a password, once in a while). Personally, I’d rather put effort into per-device passwords or, maybe even better, certificates, then putting effort into this.

But maybe I am missing an attack vector? All this is written with the assumption that the OS properly destroys the content of returned pages. Yes, swapping could cause your password to be stored on disk, but then again, if you have high security demands then you want to use certificates in the first place (which can be, at least on modern mobile platforms, stored securely).