5 ms·

KeePass2 v 2.34 to fix update security problem

73 points by SNvD7vEJ 10y ago

From the KeePass site: http://keepass.info/help/kb/sec_issues.html#updsig 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. 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). Downloads page: http://keepass.info/download.html Edit: The update has NOT yet been released, as of (CET 11:30 2016-06-06)

VoidWhisperer 10y ago
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 10y ago
  Of course not. Isn't laziness one of the traits of talented programmers?
  - simik 10y ago
    No, not that ignore-security-until-too-late type of laziness. More of a automate-manual-tasks laziness.
- Esau 10y ago
  Evidently, money is more important that security.
  - OliverJones 10y ago
    Ummm. Dominick Reichl makes Keepass available free of charge. It's not easy to stay ahead of smart, motivated and unscrupulous cybercriminals. The best thing to do if you want quicker response to threats is to send him a donation.
    - psook 10y ago
      He doesn't make it free, he makes ad money. You are the product in his mindset, and that should lead to an impasse to ever using his software for security purposes. Any user seeking security and Dominick Reichi have competing interests.
      - jdmichal 10y ago
        That philosophy works fine for something like Google, where your information is what they make money off of. In this case, your page views are the product, as KeePass does not ask for nor use for marketing any personal information from you. Huge difference.
dchest 10y ago
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.
- deleted 10y ago
  [deleted]
- SNvD7vEJ 10y ago
  So, a MITM would be able to prevent automatic update notifications?
  - dchest 10y ago
    Yes.
  - sooper 10y ago
    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 10y ago
      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 10y ago
3onyc 10y ago
Why don't they put the update file on a subdomain with HTTPS enabled? No ad revenue lost that way.
- pfg 10y ago
  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.
Sephr 10y ago
> 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.
- 0942v8653 10y ago
  If it's cryptographically signed and you found the public key from a more reputable place, you are ok. This is how apt repositories work - they use HTTP, but since everything is signed, mitm attacks can't do much other than see which packages you install.
  - Sephr 10y ago
    Almost nobody is going to search for external sources to verify the content on keepass.info > mitm attacks can't do much other than see which packages you install On the contrary, if you MitM the entire downloads page you can simply offer up a hacked/backdoored version of the software. There is no signature check if you remove the signature check in the version that you distribute.
    - mseebach 10y ago
      That's the fundamental trust-bootstrapping problem. You need an independent way to establish trust in the first interaction. In SSL, it's the (very flawed) CA model (never mind that nothing about SSL protects you if the website content is compromised). In this case, you can verify the download file signatures on keybase.io which is probably significantly safer than the CA model is. Sure, in this day and age, it's slightly disconcerting to see a security-related website that isn't SSL, but on the other hand, the tendency to blindly trust the green padlock is probably even more dangerous. http://keepass.info/integrity_sig.html http://keepass.info/integrity_sig.html https://keybase.io/reichl https://keybase.io/reichl
BerSerKer 10y ago
Since the post about this problem a few days ago I've stopped using KeePass and began using Password Safe. Good program.
cyphar 10y ago
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 10y ago
  Probably because TUF is 100% Python, and KeePass is a .NET-based Windows app.
  - cyphar 10y ago
    TUF is a specification (with a sample implementation in Python). There are Go implementations as well, for example.
    - dogma1138 10y ago
      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.
pieter_mj 10y ago
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.

73 points by SNvD7vEJ 10y ago

VoidWhisperer 10y ago

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 10y ago
Of course not. Isn't laziness one of the traits of talented programmers?
- simik 10y ago
  No, not that ignore-security-until-too-late type of laziness. More of a automate-manual-tasks laziness.
Esau 10y ago
Evidently, money is more important that security.
- OliverJones 10y ago
  Ummm. Dominick Reichl makes Keepass available free of charge. It's not easy to stay ahead of smart, motivated and unscrupulous cybercriminals. The best thing to do if you want quicker response to threats is to send him a donation.
  - psook 10y ago
    He doesn't make it free, he makes ad money. You are the product in his mindset, and that should lead to an impasse to ever using his software for security purposes. Any user seeking security and Dominick Reichi have competing interests.
    - jdmichal 10y ago
      That philosophy works fine for something like Google, where your information is what they make money off of. In this case, your page views are the product, as KeePass does not ask for nor use for marketing any personal information from you. Huge difference.

dchest 10y ago

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.

deleted 10y ago
[deleted]
SNvD7vEJ 10y ago
So, a MITM would be able to prevent automatic update notifications?
- dchest 10y ago
  Yes.
- sooper 10y ago
  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 10y ago
    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 10y ago

3onyc 10y ago

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

pfg 10y ago
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.

Sephr 10y ago

> 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.

0942v8653 10y ago
If it's cryptographically signed and you found the public key from a more reputable place, you are ok. This is how apt repositories work - they use HTTP, but since everything is signed, mitm attacks can't do much other than see which packages you install.
- Sephr 10y ago
  Almost nobody is going to search for external sources to verify the content on keepass.info > mitm attacks can't do much other than see which packages you install On the contrary, if you MitM the entire downloads page you can simply offer up a hacked/backdoored version of the software. There is no signature check if you remove the signature check in the version that you distribute.
  - mseebach 10y ago
    That's the fundamental trust-bootstrapping problem. You need an independent way to establish trust in the first interaction. In SSL, it's the (very flawed) CA model (never mind that nothing about SSL protects you if the website content is compromised). In this case, you can verify the download file signatures on keybase.io which is probably significantly safer than the CA model is. Sure, in this day and age, it's slightly disconcerting to see a security-related website that isn't SSL, but on the other hand, the tendency to blindly trust the green padlock is probably even more dangerous. http://keepass.info/integrity_sig.html http://keepass.info/integrity_sig.html https://keybase.io/reichl https://keybase.io/reichl

BerSerKer 10y ago

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

cyphar 10y ago

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 10y ago
Probably because TUF is 100% Python, and KeePass is a .NET-based Windows app.
- cyphar 10y ago
  TUF is a specification (with a sample implementation in Python). There are Go implementations as well, for example.
  - dogma1138 10y ago
    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.

pieter_mj 10y ago

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.