Security advisories for Wednesday
Fedora has a big KDE update for F18, fixing a flaw in the way PasteMacroExpander performs password generation. The following packages have been updated: audiocd-kio, analitza, bovo, bomber, blinken, kdeplasma-addons, ark, cantor, dragon, filelight, gwenview, juk, granatier, kajongg, kalgebra, kamera, kalzium, kanagram, kapman, kate, kblackbox, kaccessible, kactivities, katomic, jovie, kblocks, kbreakout, kbounce, kbrunch, kcalc, kcharselect, kcolorchooser, kdeartwork, kde-baseapps, kdeadmin, kdeaccessibility, kde-base-artwork, kdeedu, kdebindings, kdegraphics, kdegames, kdegraphics-mobipocket, kdegraphics-strigi-analyzer, kdenetwork, kde-l10n, kdemultimedia, kdegraphics-thumbnailers, kdelibs, kdepim, kde-print-manager, kdepim-runtime, kdesdk, kdeutils, kde-wallpapers, kde-workspace, kdetoys, kfloppy, kdf, kde-runtime, kfourinline, kdiamond, kgeography, kgamma, kgoldrunner, kgpg, killbots, kiriki, kigo, kig, khangman, kjumpingcube, kiten, klickety, klines, klettres, kimono, kmag, kmahjongg, kmines, kmix, kmousetool, kmplot, kmouth, knetwalk, kolf, knavalbattle, kollision, konquest, kolourpaint, kremotecontrol, kreversi, kruler, ksameplugin, kscd, kross-interpreters, konsole, kshisen, kpat, ksnakeduel, ksirk, kspaceduel, ksnapshot, ksudoku, ksquares, kstars, ktouch, ktimer, kturtle, ktuberling, kwallet, kubrick, kwordquiz, libkcddb, libkdegames, libkexiv2, libkipi, libkmahjongg, lskat, nepomuk-core, marble, libksane, nepomuk-widgets, libkdcraw, libkcompactdisc, libkdeedu, okular, palapeli, oxygen-icon-theme, pairs, parley, pykde4, smokegen, ruby-qt, smokekde, ruby-korundum, smokeqt, picmi, qyoto, rocs, step, superkaramba, svgpart, sweeper, and kdepimlibs.
Mandriva has updated wireshark (multiple vulnerabilities).
Oracle has updated kernel (OL6: multiple vulnerabilities).
Red Hat has updated flash-plugin (code execution).
Ubuntu has updated php5 (13.04: code
execution) and telepathy-gabble (denial of
service/man-in-the-middle attack).
Posted Jun 12, 2013 19:13 UTC (Wed)
by krakensden (subscriber, #72039)
[Link] (8 responses)
Not knowing much about security, but having an interest in it- why is this variety of password so easy to crack? Is it the prng? The definite length?
Posted Jun 12, 2013 21:21 UTC (Wed)
by jimparis (guest, #38647)
[Link]
That's just horrendous. For starters, there's a 1 in 1000 chance that
For example: let's say you know that someone generated a password in the hour between 2013-06-01 18:00 and 2013-06-01 19:00. Going through this code for all possible millisecond values gives a total of just 27878 passwords that could have been generated. That's less than 15 bits of randomness -- equivalent to three lowercase letters chosen at random.
Even if you only know when a password was generated to within a month between 2013-05-01 and 2013-06-01, there are still just 19561093 values to try -- easy if you're trying to crack a hashed password, and
still only equivalent to a five character password.
Posted Jun 12, 2013 21:21 UTC (Wed)
by Kit (guest, #55925)
[Link] (6 responses)
1) It's seeded with the time. If the attack knows around when the password was generated, they can just start trying seeds around that time.
2) They're doing "qrand() % chars.count()", which won't result in a uniform distribution of random numbers (depending on chars.count()). They should have done qrand(chars.count()), assuming qrand is decently implemented. Think how if you're choosing random numbers with the (inclusive) range 0-5, if you then mod the result by 4, you're going to get FAR more 0s and 1s than 2s and 3s (because 4 will also map to 0, and 5 to 1... nothing extra maps to 2 or 3).
3) According to Qt's documentation, qrand() is intended to just be a thread-safe version of rand()... Seeing as rand() doesn't even pretend to be a cryptographically secure PRNG, qrand() is likely no better in that regard.
Posted Jun 13, 2013 0:06 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link]
Posted Jun 13, 2013 7:02 UTC (Thu)
by therealmik (guest, #87720)
[Link] (4 responses)
The presence of easy to use insecure RNGs, and the fact that secure RNGs are almost all hard to use (eg. a bitstream) is a major problem.
IMO distros should just replace rand() and friends with a secure rng and ignore srand()
Posted Jun 13, 2013 15:56 UTC (Thu)
by anselm (subscriber, #2796)
[Link] (3 responses)
There is nothing wrong with rand() and friends if you use them as designed.
The rand(3) man page is very up-front about the fact that the rand() and rand_r() functions produce pseudo-random numbers. They are great if you want reproducible »random« numbers for debugging computer games and that sort of thing, where crypto-quality randomness is neither required nor desirable.
If people then try to (ab)use these functions to do something else entirely, namely produce real random numbers suitable for cryptographic or otherwise security-related purposes, it is hardly the functions' fault if the people in question can't (or won't) read.
Posted Jun 13, 2013 16:25 UTC (Thu)
by mpr22 (subscriber, #60784)
[Link]
Posted Jun 13, 2013 17:03 UTC (Thu)
by Kit (guest, #55925)
[Link]
Saying it's a PRNG does _not_ mean it's inappropriate for cryptography/security... not in the slightest. Most systems don't have access to much (if any) /real/ random numbers (hardware RNGs aren't too common). Hell, the man page for urandom actually recommends using it as the source for a RPNG, instead of using it directly.
Unfortunately, rand() is a bad PRNG. It being a bad one is what makes it inappropriate.
> They are great if you want reproducible »random« numbers for debugging computer
Actually, rand() is usually not very good choice for games either. It's very bad on the 'random' front (so you're likely to get patterns in the output... and a lot of gamers obsess over finding those sorts of things), while at the same time it's also rather slow.
IIRC, the reason rand() hasn't been improved was worry that it might break some programs. I might be misremembering the exact reason, though.
Posted Jun 14, 2013 2:29 UTC (Fri)
by therealmik (guest, #87720)
[Link]
The fact is:
So, let's just make rand() and friends silently be a randomly seeded crypto rng - any software that needs the old rand()-style rng can just copy the old code, in the mean time we've patched at-least hundreds of major security bugs on our desktops and servers.
Posted Jun 12, 2013 21:21 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link]
Posted Jun 12, 2013 23:55 UTC (Wed)
by therealmik (guest, #87720)
[Link]
It uses KRandom, which has a max 32 bits of seed.
If you used KDE Paste to generate passwords, go change them now - I posted an external mode for JtR to john-users if you need to audit your password files to help find them, or you could use
https://github.com/therealmik/passgen-fun/blob/master/kde... and pipe into john --stdin (the python version is more user-friendly).
To replace, call a different random password generator, but not the patched KDE Paste, and use 'pwgen' with caution...
Posted Jun 14, 2013 1:35 UTC (Fri)
by butlerm (subscriber, #13312)
[Link] (1 responses)
Posted Jun 14, 2013 2:05 UTC (Fri)
by dlang (guest, #313)
[Link]
Security advisories for Wednesday
The random number generator is seeded with:
Security advisories for Wednesday
QDateTime now = QDateTime::currentDateTime();
qsrand(now.toTime_t() / now.time().msec());
now.time().msec() is zero and the code will crash with a division by zero error. Second, you can often guess when, to within some accuracy, a particular password was generated, which means you can guess a range for the now.toTime_t() value. Combine this with iterating through the 999 possible values of now.time().msec() and you've got a really good chance of guessing what the random seed was, and therefore, the password. Especially since qsrand() only takes integer input!
Security advisories for Wednesday
Security advisories for Wednesday
Security advisories for Wednesday
Security advisories for Wednesday
Any computer game that uses rand() for any purpose other than driving cosmetic animations almost certainly shouldn't.
Security advisories for Wednesday
Security advisories for Wednesday
> functions produce pseudo-random numbers.
> games and that sort of thing, where crypto-quality randomness is neither required nor desirable.
Security advisories for Wednesday
- Nothing I use needs "repeatable" random numbers.
- Nothing I use needs the original rand() or random() behaviour - they all seem to treat it as an rng that never repeats.
- I've found 4 password generator bugs so far, and almost all are using a default rand() function with what they think is good seeding. Explaining this is difficult, and "I'm not trying to secure Fort Knox here" is a not-uncommon reply
Security advisories for Wednesday
Security advisories for Wednesday
Security advisories for Wednesday
Security advisories for Wednesday