
KeePass2 v 2.34 to fix update security problem - SNvD7vEJ
From the KeePass site: http:&#x2F;&#x2F;keepass.info&#x2F;help&#x2F;kb&#x2F;sec_issues.html#updsig<p><i>In order to prevent a man in the middle from making KeePass display incorrect version information (even though this does not imply a successful attack, see above), the version information file is now digitally signed (using RSA-2048 and SHA-512).<p>KeePass 2.34 and higher only accept such a digitally signed version information file. This solution is more secure than just using HTTPS, because it guarantees version information safety even when the webserver is compromised (the private key for signing the version information is not stored on the webserver).</i><p>Downloads page: http:&#x2F;&#x2F;keepass.info&#x2F;download.html<p>Edit:
The update has NOT yet been released, as of (CET 11:30 2016-06-06)
======
dchest
This is a partial fix, but it's not enough. An attacker performing man-in-the-
middle attack can respond with the previous version of "version information
file", preventing the update.

Imagine if there's a vulnerability in one version of KeePass2, and the fix is
available for it. MiTM attacker sends the previous version so that the app
doesn't know that there's an update, and the attacker has more time to use the
vulnerability.

HTTPS prevents this. They should do both.

~~~
SNvD7vEJ
So, a MITM would be able to prevent automatic update notifications?

~~~
sooper
It seems not any more?:

 _" Resolution. In order to prevent a man in the middle from making KeePass
display incorrect version information (even though this does not imply a
successful attack, see above), the version information file is now digitally
signed (using RSA-2048 and SHA-512). KeePass 2.34 and higher only accept such
a digitally signed version information file. Furthermore, the version
information file is now downloaded over HTTPS."_

~~~
dchest
The question was if MITM would be able to prevent automatic update
notifications. Their solution doesn't solve this: it prevents attackers from
changing version information, but doesn't prevent them from replaying previous
version information.

~~~
SNvD7vEJ
How would that work? ("replaying")

------
Sephr
> Downloads page: _http_ ://keepass.info/download.html

I still see a glaring MitM vulnerability…

Until the author actually switches to HTTPS, network operators can simply
hijack the original downloads page in the first place. This update is barely a
mitigation.

If he wants more ad revenue, his only option is to find another ad network.
Eventually someone else is going to start hosting a popular fork on a
different HTTPS site if he keeps stubbornly ignoring this issue.

~~~
Nutomic
That fork is KeePassX [1]. And it's cross-platform too!

[1] [https://www.keepassx.org/](https://www.keepassx.org/)

~~~
drdaeman
Sadly, there is no sync and syncing offline changes is non-trivial in KeePass.

(At the very least, a .kdbx on Syncthing/Droxbox-like storage WILL eventually
lead to data loss.)

~~~
Flott
AFAK if a conflict occure, it will create a "conflicted copy" of the kdbx
file. You still have to merge files manually but no data will be lost in the
process.

~~~
brerlapn
This is correct--I've had conflicts and a second kdbx file is created with
conflicted copy and the date of the conflict in the filename.

It's a small pain to go through and figure out which item is out of sync, but
doable.

------
cyphar
Why not just switch to using The Update Framework (TUF)[1]. It solves many,
many, many attacks against updating systems and we really should be using it
everywhere.

[1]:
[https://theupdateframework.github.io/](https://theupdateframework.github.io/)

~~~
j_s
Probably because TUF is 100% Python, and KeePass is a .NET-based Windows app.

~~~
cyphar
TUF is a specification (with a sample implementation in Python). There are Go
implementations as well, for example.

~~~
dogma1138
Because they'll have to implement it in .Net which is not a small task.

Even if there is an implementation in .Net it will have to be audited and even
then you are at the mercy of who ever maintains it.

Sucking in OSS libraries might sound easy and smart but it's a huge gamble
unless it's a defacto standard in the industry or is being maintained by a
giant corporation you might be stuck up the creek without a paddle as soon as
the person maintaining it decides to drop it.

------
3onyc
Why don't they put the update file on a subdomain with HTTPS enabled? No ad
revenue lost that way.

~~~
pfg
There's a good argument to be made for signing the update information using
offline keys - it reduces the damage that could be caused by a compromised SSL
key. That being said, they should've still used HTTPS to secure the transport
layer, as it would prevent replay attacks (as @dchest mentioned) and make it
harder to exploit vulnerabilities that could be caused by e.g. corrupted
update information.

------
VoidWhisperer
My question is: Would they have released this update if the person who came
forward about the fact that KeePass said that they wouldn't fix it didn't?

~~~
toyg
Of course not. Isn't laziness one of the traits of talented programmers?

~~~
simik
No, not that ignore-security-until-too-late type of laziness. More of a
automate-manual-tasks laziness.

------
BerSerKer
Since the post about this problem a few days ago I've stopped using KeePass
and began using Password Safe. Good program.

------
pieter_mj
Allowing these type of programs to autonotify of updates and self-update
should be considered bad practice and a high security risk.

Why risk a malicious MITM-ed update? The keepass site should just provide
portable zips and off-site hashes and sigs for verification.

