[Noisebridge-discuss] pip install secureconfig (actual hacking!)

[Josh Juran]

On Apr 21, 2014, at 11:22 PM, Naomi Most <pnaomi at gmail.com> wrote:

> I made a library called secureconfig for python and pushed its first
> minor release version earlier today.
> 
> https://pypi.python.org/pypi/secureconfig
> 
> https://bitbucket.org/nthmost/python-secureconfig
> 
> 
> secureconfig provides interfaces to (currently 3) data structures,
> including the .ini style data people like to use the configparser
> class with.  You can encrypt/decrypt using keys stored in environment
> variables, files, or strings.

Environment variables may be visible to all users on a system, even guest users.

> There's also a nifty class called SecureString that automatically
> zeroes its string data after garbage collection or if you explicitly

I once encountered a C++ class of the same name.  Sure enough, the destructor overwrote the memory before deallocating it. Unfortunately, the only way to get data into a "secure" string was to construct it from a non-secure string... whose destructor did *not* clear its memory on the way out.

> call the "burn" method.  So if you're really paranoid you can do this:
> 
> scfg = SecureConfigParser.from_env(NAME_OF_ENV)
> scfg.read('/path/to/config.ini')
> 
> password = SecureString(scfg.get('credentials', 'password'))
> 
> cnxn = ConnectToSomething(password)
> 
> # overwrite string data with zeroes:
> password.burn()

In order to make this work you need to be operating at system level.  I see you've arranged to call C's memset(), but are you sure that python hasn't made other copies of the data?  I'd be more comfortable if this were something built into the language, e.g. a command-line switch or language pragma that zeroes *all* strings on destruction, so you only pay for it when you want it, but once it's in effect it just works so you can't screw it up easily.

> You can easily recover plaintext data from a memory dump with root
> access, so the burn function is handy if you don't completely trust
> everyone you've ever given sudo to.

Giving superuser privileges to someone you don't trust completely is a contradiction.  Root can read the file where the key was stored.  Root can modify your Python library or the python executable (in memory or on disk).  Root can install a keylogger.  To share root *is* to trust completely.  How good an idea you feel that might be is another matter.

Anyway, there's a window of opportunity between when the password is loaded or entered and when it's destroyed.  A user who can read your process' memory at all will also have ways of widening the window, e.g. sending SIGSTOP or attaching via ptrace() (or modifying your script to log the password).

> This is the first time I've ever made a library that makes claims
> about "security", and I want to make sure it gets picked apart
> appropriately.  So feel free to critique code and documentation here.


I've never looked at Python extension code before (so weight my remarks appropriately), but I'm disturbed by the sheer amount of boilerplate code in secureconfig/zeromem.c.

<https://bitbucket.org/nthmost/python-secureconfig/src/04469e8ff00d50afad6a22ec3b37b147178cb0fa/secureconfig/zeromem.c>

I'm not a cryptographer or infosec expert, and I'm not qualified to make assurances regarding security, but I'm a skilled programmer and mostly know what I'm talking about.

I hope that helps.

Josh