[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#873955: RFP: selfspy -- log everything you do on the computer, for statistics/fun etc.



Control: owner -1 anarcat@debian.org
Control: retitle -1 ITP: selfspy -- log everything you do on the computer, for statistics/fun etc.

On 2017-09-06 07:55:53, Chris Lamb wrote:
> Hi Antoine,
>
>> May I suggest we audit the hell out of the code of tools like this
>> before they come into Debian? :)
>
> Oh sure. And ones already in Debian I hope!

Just that? :)

I'll start with that one since that's the one I'm currently interested
in if you don't mind.

At first look, the program looks well-written. It uses sqlalchemy for
storage in a SQLite database and while it doesn't have any unit tests,
it looks like it has a sound design. I didn't review the cocoa or
Windows code (specifically `sniff_cocoa.py` and `sniff_win.py`), so
the following applies only to the X version.

Entries can be encrypted in the database. The program uses Python's
getpass module to prompt for passwords on the commandline and Tk's
`Entry` element in the GUI, which probably leaks the password all over
the memory space (and may show it to the user). The pinentry program
should be used instead.

But That password is problematic in the first place since you need to
either type it every time you start the program (which is annoying) or
hardcode it on the commandline (which is insecure) or the config file
(which is pointless). A better approach would be to use OpenPGP to
encrypt the database (filed an [issue][openpgp] about this).

 [openpgp]: https://github.com/gurgeh/selfspy/issues/155

Furthermore, Blowfish to encrypt data stored in the database. Because
of its 64-bit blocksize, Blowfish is considered problematic for large
file encryption as
it's [vulnerable to birthday attacks][blowfish]. Furthermore, MD5 is used to
derive a key from the user password, which also shows its age. A
better approach would be to use a more standard SQLite encryption
approach like [SQLcipher][]. An ideal design, in my mind, would be to
have an AES-encrypted SQLite database with a strong key encrypted with
a user password using a proper key derivation function (KDF) like
Argon, scrypt or PBKDF2 (probably in that order). Also filed an
[issue][] about this.

 [blowfish]: https://en.wikipedia.org/wiki/Blowfish_(cipher)#Weakness_and_successors
 [SQLcipher]: https://www.zetetic.net/sqlcipher/
 [issue]: https://github.com/gurgeh/selfspy/issues/159

So that's for the security of the encrypted storage: basically, it's
showing its age, but should be good enough for casual attackers. As I
mentioned before, a better option would be to *not* store keystrokes
text by default and explicitly force the user to enable this by hand
if they really want a keylogger running at all time. I have also made
a [PR][] for that feature.

 [PR]: https://github.com/gurgeh/selfspy/pull/158

The keylogger itself uses what looks like [Python's Xlib][python-xlib] and
relies on the [RECORD][] extension which will stream all keystrokes
for all clients to the application, regardless of whether or not
keylogging is enabled. This will force administrators to enable that
possible security liability on the X server in order for users to use
this app, but that's a fundamental limitation of X more than an issue
with this particular app.

 [python-xlib]: https://pypi.python.org/pypi/python-xlib
 [RECORD]: https://www.x.org/releases/X11R7.6/doc/recordproto/record.html

Finally, while I cannot vouch for the software without a more thorough
review, I can say that I have read through the code and didn't find
any obvious "leakage" out of the SQLite storage. It doesn't look like
the program sends keystrokes on the network or publicly-readable
files.

As for Debian packaging, that should be fairly straightforward: all
dependencies (lockfile, sqlalchemy, keyring, xlib, although the latter
is [missing from requirements][]) are already in Debian and it's a
fairly normal Python program. I have filed a PR
to [remove the Makefile][] to avoid possible debhelper confusion.

I'll be using the program a little more to figure out if there are any
other gotchas and upload if all is well.

 [remove the Makefile]: https://github.com/gurgeh/selfspy/pull/156
 [missing from requirements]: https://github.com/gurgeh/selfspy/pull/157

Thanks for finding that awesome software. :)

A.

-- 
You Are What You Is
                        - Frank Zappa


Reply to: