Avoiding data theft from within program memory. Ideas?

Discussion in 'other security issues & news' started by Gullible Jones, Dec 15, 2014.

  1. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,466
    After seeing what looked an awful lot like the beginnings of a compromise on my laptop yesterday, I'm working on some ideas/guidelines for reducing the scope of compromise when it occurs; particularly as relates to data theft from within the browser. I'm limiting this to practical stuff - e.g. object-capability based security would be very nice, but nobody's doing that in a practical fashion yet.

    Thought 1: minimize the amount of data stored in the browser, and the amount of time it persists for.

    So: use a password vault, and C&P your passwords from there. Make all cookies session-only, and tell the browser to wipe everything on closing. Maybe disable history, if there's anything sensitive or worth stealing there. Likewise, keep frequently visited URLs in a password-protected external list, if bookmarks would otherwise reveal more stuff an attacker might want to snoop on.

    This is pretty easy to do in any modern browser, and I don't think it would be seriously inconvenient.

    Thought 2: use temporary "sandbox" user accounts.

    Each browser or chat session would run in a temporary user account with a random name and uid. On closing, the user would be given a chance to recover downloaded (non-hidden) files. Everything else would be wiped...

    Yes, I'm talking about a budget version of Sandboxie for Linux, more or less. With correct permissions on home dirs, this has the advantage that it would make snooping on other user account data more difficult - not prohibitive, but not so easy (especially in combination with a halfway decent AppArmor policy).

    You could also do this with VMs, at the cost of much more RAM, inconvenience, and setup time. For casual users, I'm not sure that's worthwhile.

    Thought 3: Store anything sensitive in an encrypted virtual filesystem or archive

    More damage mitigation stuff. Trawling through memory for the password requires root. Keylogging it is possible, but probably not trivial from inside a decent AppArmor profile (or so I would tend to think!).

    Thoughts? Comments? Anyone?
     
  2. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,559
    Location:
    The Netherlands
    If you're browser is not infected then data theft should not be possible in the first place. So browser memory should be protected, let's say if you have malicious software running then code-injection should be blocked and some HIPS also block reading of process memory. Of course there is also file-less malware that get triggered by exploits, the only way to stop them is via anti-exploit tools like EMET/HMPA/MBAE.
     
  3. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,466
    I'm assuming here that an exploit has already been run successfully. :)

    Really protecting browser memory would be the object-capability security I mentioned, which is way beyond what any extant HIPS can do. There is Capsicum, a framework for it on Linux and BSD, but that's very experimental and requires application support. And there's a kernel patchset (I forget the name...) for enforcing object oriented access restrictions, but that's even more experimental, and right now mostly just breaks things.

    Exploit mitigation on Linux would be GrSecurity, or current RSBAC/PAX. The stock kernel also has some mitigation measures, which IIRC are fairly strong on 64-bit. Not so much on 32-bit though (and guess which my laptop was running?). Personally I have experienced all kinds of basic functionality and stability problems with GrSec, so I don't use it day to day.
     
  4. safeguy

    safeguy Registered Member

    Joined:
    Jun 14, 2010
    Posts:
    1,795
    This may not be the answer you are looking for but here goes my thoughts....

    If I had highly sensitive data for which securing it is of paramount importance, I would only trust having it on an offline air-gap system.

    Have a look here:
    https://www.schneier.com/blog/archives/2013/10/air_gaps.html

    If one does not trust browsing session to be relatively "safe", one can browse using Live USB on another system with no data OR a dedicated machine whereby security/privacy of the data is of no importance (iotw, compromise is more of an inconvenience than something major that is at stake)

    I've practically given up on the idea of securing my data on a system that's connected. The browser is the biggest threatgate - it is able to interact with my data and upload it (for convenience) so if it's compromised, I might as well assume my data is compromised too. Here encryption and restricted filesysyem access might present as mitigation factors but I wouldn't like to count on them against someone who is keen to steal my data.
     
  5. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,466
    I feel like that would be way overdoing it, honestly. Create more inconvenience than it's worth given what my personal data consists of.

    Currently trying a different tactic - IP address whitelisting, like I was cooking up earlier. I have some improvements to the UFW whitelisting program, I will post them. So far so good (and the bonus is that I spend less time reading stupid webcomics :p ).
     
  6. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,559
    Location:
    The Netherlands
    Well, I don't know anything about Linux but if the browser is already compromised it's quite hard to stop data theft. However, we discussed this in another thread, in theory you can restrict the browser from as much privileges as possible, that might help.
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.