Slashdot Mirror

>"its embedded server encryption hardware that tests the authenticity of a platform and its operating system before sharing data"

Translation: "Use our proprietary hardware and software and forget about using anything open-source like Linux".

Reminds me a lot of that horrible, crappy "Trusteer" junk that some banks are trying to force on people, especially corporate customers. https://www.trusteer.com/Prote...

Does Google Chrome have a cryptographic-grade random number generator with a good source of enthropy? Javascript math.random() is known to be predictable. Has someone with respected crypto qualifications checked over the code and signed off on it?

Chrome already has facilities for generating random numbers for generation of SSL session keys (or inputs to generation of SSL session keys) and for generation of key pairs. I've never looked at the source, but we also haven't heard about any issues with Chrome in those contexts. I would expect that Chrome uses the OS-provided RNG (e.g. /dev/random) facilities where available.

Does Google Chrome have a cryptographic-grade random number generator with a good source of enthropy? Javascript math.random() is known to be predictable. Has someone with respected crypto qualifications checked over the code and signed off on it?

From the source site (the blog at http://www.trusteer.com/

"The good news is that Trusteer's Rapport secure web access software- which is now in use by millions of online banking customers - can prevent OddJob from executing."

Now, I don't know Trusteer's rep, but when I see a story like this that originates from what appears to be a source that's in the business of selling security software, I want a second opinion from another source. A quick "google" for OddJob finds stories that all seem to tie back to Trusteer's blog entry. This story also doesn't say much about platform sensitivity. Is this an issue on any OS platform that uses Firefox, for example?

One detail in the report struck me: the claim that they capture all web traffic and store it in an SQL server w/ a search frontend at CNC. This is evidently unfeasible, they would have to filter out only data posted into forms and the like. It would have been helpful had the report told about what "shape" this data took, what kind of auth mechanisms was leeched from. They had no whitepaper/analysis on their website, but there was this OS distribution pie chart: http://www.trusteer.com/sites/default/files/ZeusbotnetOSstats.jpg
Still, imagine having a line into that kind of setup, on a pay per-password-search basis.

The PDF that is linked to in TFA states explicitly that this does not involve the use of 'protected' resources to determine if you are logged in or not. This is, in fact, a different vulnerability exposed by JavaScript.

Link for the lazy: http://www.trusteer.com/files/In-session-phishing-advisory-2.pdf, page 2 paragraphs 3 and 4.

I refer you to this post.

http://undeadly.org/cgi?action=article&sid=20070725193920

Jakob Schlyter (jakob@) wrote to misc@:

        as some of you may have noticed, a new weakness in BIND 9 has
        recently been discovered. using this weakness, an attacker can
        remotely poison the cache of any BIND 9 server. the attacker can do
        this due to a weakness in the transaction ID generation algorithm used.

        when BIND 9 was first imported into OpenBSD, we decided not to use
        the default ID generation algorithm (LFSR, Linear Feedback Shift
        Register) but to use a more proven algorithm (LCG, Linear
        Congruential Generator) instead. thanks to this wise decision, the
        BIND 9 shipped with OpenBSD does not have this weakness.

        the proactive security of OpenBSD strikes again,

                        jakob

        ref: http://www.trusteer.com/docs/bind9dns.html

The paper shows that BIND 9 DNS queries are predictable i.e. that the source UDP port and DNS transaction ID can be effectively predicted. A predictability algorithm is described that, in optimal conditions, provides very few guesses for the "next" query (10 in the basic attack, and 1 in the advanced attack), thereby overcoming whatever protection offered by the transaction ID mechanism. This enables a much more effective DNS cache poisoning than the currently known attacks against BIND 9. The net effect is that pharming attacks are feasible against BIND 9 caching DNS servers, without the need to directly attack neither DNS servers nor clients (PCs). The results are applicable to all BIND 9 releases [1], when BIND (the named daemon) is in caching DNS server configuration.