From ${URL}: I just noticed this is now public: <http://gaganpreet.in/blog/2013/07/24/kwallet-security-analysis/> Short summary: kwallet uses Blowfish to encrypt its password store, and despite an attempt at implementing CBC mode (in a file called cbc.cc no less), it's actually ECB mode. UTF-16 encoding combined with Blowfish's 64 bit block size means there are just four password characters per block. Encryption is convergent as well. This may enable recovery of passwords through codebook attacks.
Is this reported upstream?
I think upstream is vaguely aware, but there's no bug about it. There's not much we can do - the code can't change otherwise it will break existing wallets. We could enable gpg support by default in kwalletd which offers better protection, but note that pulls in kdepimlibs too.
*** Bug 536088 has been marked as a duplicate of this bug. ***
For kde-runtime KWallet upgrade to KDE Applications 14.12.1 or apply the following patch: http://quickgit.kde.org/?p=kde-runtime.git&a=commit&h=14a8232d0b5b1bc5e0ad922292c6b5a1c501165c For KDE Frameworks 5 KWallet upgrade to 5.6.0 or apply the following patch: http://quickgit.kde.org/?p=kwallet.git&a=commit&h=6e588d795e6631c3c9d84d85fd3884a159b45849
(In reply to Agostino Sarubbo from comment #4) > For kde-runtime KWallet upgrade to KDE Applications 14.12.1 or apply the > following patch: > > http://quickgit.kde.org/?p=kde-runtime. > git&a=commit&h=14a8232d0b5b1bc5e0ad922292c6b5a1c501165c + + 20 Jan 2015; Johannes Huber <johu@gentoo.org> + +files/kwalletd-4.14.3-CVE-2013-7252.patch, +kwalletd-4.14.3-r1.ebuild: + Revision bumps backports upstream patch to fix CVE-2013-7252, bug #496768. + > For KDE Frameworks 5 KWallet upgrade to 5.6.0 or apply the following patch: > > http://quickgit.kde.org/?p=kwallet. > git&a=commit&h=6e588d795e6631c3c9d84d85fd3884a159b45849 + + 09 Jan 2015; Manuel Rüger <mrueg@gentoo.org> +kwallet-5.6.0.ebuild, + -kwallet-5.5.0.ebuild: + Version bump. + Arches please stabilize kde-base/kwalletd-4.14.3-r1
amd64 stable
I upgraded yesterday and I can't access some of my wallets anymore. To be precise I have two wallets, one is always open and the other is always closed. After the upgrade, the wallet that was open during the emerge opens only with the new kwalletd. The wallet that was closed during the emerge, opens only with the old kwalletd. In order to fix the issue I downgraded kwalletd, exported my wallet and imported it in the new version. Furthermore this fix seems half baked since I can't close anymore a wallet encrypted with GPG. I press the close button, the wallet seems closed but when I press open it opens without asking for a password. It only asks for my GPG password at the first time since login. Even worse maybe, the GPG dialog has the password visible.
(In reply to Marios Andreopoulos from comment #7) > I upgraded yesterday and I can't access some of my wallets anymore. To be > precise I have two wallets, one is always open and the other is always > closed. > > After the upgrade, the wallet that was open during the emerge opens only > with the new kwalletd. > The wallet that was closed during the emerge, opens only with the old > kwalletd. exactly the same issue here. is there any command to manually triogger the wallet upgrade?
For an old wallet without a .salt file, this new version will generate one first with the result, that the password of the wallet is no longer valid!
x86 stable
ppc64 stable
ppc stable. Maintainer(s), please cleanup. Security, please vote.
Thanks all. Cleanup done. Removing kde herd from cc, as it is nothing to do for us anymore. + + 18 Feb 2015; Johannes Huber <johu@gentoo.org> -kwalletd-4.14.3.ebuild: + Remove old, bug #496768 +
Arches and Maintainer(s), Thank you for your work. Vote: Yes
(In reply to Yury German from comment #14) > Arches and Maintainer(s), Thank you for your work. > > Vote: Yes GLSA Vote: Yes, new request filed
CVE-2013-7252 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-7252): kwalletd in KWallet before KDE Applications 14.12.0 uses Blowfish with ECB mode instead of CBC mode when encrypting the password store, which makes it easier for attackers to guess passwords via a codebook attack.
This issue was resolved and addressed in GLSA 201606-19 at https://security.gentoo.org/glsa/201606-19 by GLSA coordinator Aaron Bauman (b-man).