paste widget "password" generator uses (very) insecure randomness

Here's a python script that will generate passwords for use with john. Strength of passwords makes no difference to performance, you simply need to pass it the config string (the arguments to the macro), and the startTime and endTime.

All arguments are optional - by default it starts now and ends a year ago, with the default "Random Password" setting of the applet chosen.

To use this, create a passwd-style file, eg username:encrypted_password one-per-line. mkpasswd can encrypt it for you (eg. mkpasswd --stdin --hash=md5), then run this command:

touch john.ini
./kdepastebreak.py | john --stdin passwdfile

The <email address hidden> email address hasn't responded to me, but an alert should at-least be sent to users, and a nasty error popup should be displayed to people using it, with an offer to use pwqgen or something instead (part of the passwdqc package).

I never heard back from <email address hidden> - does anyone listen to that address?

Anyway, I'll just post to bugtraq if nobody's going to look at this. Workaround is just to use %{exec(pwqgen)}.

now fixed upstream as bug 36a1fe49cb70f717c4a6e9eeee2c9186503a8dce

That patch is wrong - KRandom only takes an int as seed, which is trivial to replay. (And it falls back to srand(time(NULL)) - not a good thing, for example if an apparmor policy accidentally blocked /dev/urandom)

QCA::Random is what you're after.

... Although it seems like fixing KRandom to just fill an integer from /dev/urandom would be a win ...

Riddell,

Could you please add bb6d0ecb9f842de7bc16fa2eeed7a76662bd5752 to the debdiff also.

Mik,

Could you please communicate with upstream that you consider their patch to be wrong?

Thanks.

This bug was fixed in the package kdeplasma-addons - 4:4.10.3-0ubuntu3

---------------
kdeplasma-addons (4:4.10.3-0ubuntu3) saucy; urgency=low

  * Add kubuntu_02_random_password_generator.diff from upstream
    fixes paste widget password generator uses insecure randomness
    LP: #1179380
 -- Jonathan Riddell <email address hidden> Tue, 04 Jun 2013 11:51:38 +0100

Mik, what was upstream's response?

Upstream haven't responded to me about anything (not even the original report).

Fedora released the faulty patch - such a waste of bandwidth :(

IIRC there was some discussion about this on kde-devel and a change got committed to git. You might check there.

I can't find the commit - do you know what they changed?

On Friday, June 14, 2013 08:00:40 PM you wrote:
> I can't find the commit - do you know what they changed?

kdeplasma-addons 36a1fe49cb70f717c4a6e9eeee2c9186503a8dce

That's for trunk/4.11. There was a similar commit for 4.10, but I don't know
it's ID.

Yeah, that commit's wrong, unless they're assuming KRandom is a secure PRNG, in which case we should assign another CVE and I'll write a patch for that.

Check and make sure there wasn't another change after that.

I found this:

https://projects.kde.org/projects/kde/kdeplasma-addons/repository/revisions/0e5cecec402c42fb9ebb77f13d8bacd577da886b

I'm guessing somebody tried to push a commit and it didn't make it?

Is there any progress on this?

Last thing I heard was on oss-sec list:

Please use CVE-2013-2213 for KDE KRandom::random() CWE-334: Small
Space of Random Values.

So I guess patching KRandom to use qca::random (either using TLS or a lock) would be the easy fix that would let people sleep at night.

This issue has been rated "low" by the security team, so a fix for this issue will be bundled in the next security update that contains a "medium" or higher.

Unsubscribing sponsors for now.

quantal has seen the end of its life and is no longer receiving any updates. Marking the quantal task for this ticket as "Won't Fix".

raring has seen the end of its life and is no longer receiving any updates. Marking the raring task for this ticket as "Won't Fix".

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release