Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Security Bug

OpenSSL Bug Allows Attackers To Read Memory In 64k Chunks 303

Bismillah (993337) writes "A potentially very serious bug in OpenSSL 1.0.1 and 1.0.2 beta has been discovered that can leak just about any information, from keys to content. Better yet, it appears to have been introduced in 2011, and known since March 2012." Quoting the security advisory: "A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server." The attack may be repeated and it appears trivial to acquire the host's private key. If you were running a vulnerable release, it is even suggested that you go as far as revoking all of your keys. Distributions using OpenSSL 0.9.8 are not vulnerable (Debian Squeeze vintage). Debian Wheezy, Ubuntu 12.04.4, Centos 6.5, Fedora 18, SuSE 12.2, OpenBSD 5.4, FreeBSD 8.4, and NetBSD 5.0.2 and all following releases are vulnerable. OpenSSL released 1.0.1g today addressing the vulnerability. Debian's fix is in incoming and should hit mirrors soon, Fedora is having some trouble applying their patches, but a workaround patch to the package .spec (disabling heartbeats) is available for immediate application.
This discussion has been archived. No new comments can be posted.

OpenSSL Bug Allows Attackers To Read Memory In 64k Chunks

Comments Filter:
  • by Anonymous Coward on Monday April 07, 2014 @08:06PM (#46689601)

    "We have tested some of our own services from attacker's perspective. We attacked ourselves from outside, without leaving a trace. Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication."

    Yikes. And it's been known for 2 years. That's some shit!

    • With address space layout randomization, I can't imagine how you could probe memory for sensitive information without causing the process to randomly crash. Given how polished the website publicizing the vulnerability is, I think they're more interested in creating hype.
      • by AlphaBro ( 2809233 ) on Tuesday April 08, 2014 @02:05AM (#46691391)
        This is a read overrun, so ASLR won't save you. Ignore the guy above who posted about ASLR bypasses--that's not really relevant to this.
        • I've actually wondered about this too. Read overruns will crash a program just as badly as write overruns; Read AV in Windows [NT], Segmentation Fault in *nix (General Protection Fault in legacy Windows), etc. reading memory will tell you enough about the layout of memory to cherry-pick addresses pretty well, and probably to determine the ASLR mask, but you're still going to have the issue of what, within the heap, is allocated. You could probably do OK by starting from the stack (which is in a predictable

          • Read overruns causing occasional crashes isn't much of an issue for the attacker if the server is auto-restarting.

          • by BitZtream ( 692029 ) on Tuesday April 08, 2014 @10:39AM (#46693967)

            Read or write overruns will only throw an exception if they go beyond the bounds of the applications total allocated memory so they hit an unallocated page. (page fault)

            If you simply read into some memory that has been allocated by some other component, no exception will be thrown.

            Reading outside the bounds of the application application pages is unlikely as you'd have to be the last or close to the last allocated block (when the application space has to be grown, doesn't work if its a realloc of a previously allocated page, so lower in the address space and not near the end of allocated pages) and/or have a large overrun so you went through all the other allocated blocks.

          • I've actually wondered about this too. Read overruns will crash a program just as badly as write overruns; Read AV in Windows [NT], Segmentation Fault in *nix (General Protection Fault in legacy Windows), etc. reading memory will tell you enough about the layout of memory to cherry-pick addresses pretty well, and probably to determine the ASLR mask, but you're still going to have the issue of what, within the heap, is allocated. You could probably do OK by starting from the stack (which is in a predictable enough location) and working from there, I guess?

            ASLR was invented as a mitigation of "return oriented programming" which was itself a way to get around DEP/NX. As such, ASLR targets executable memory, making the memory addresses of candidate executable code fragments hard to guess. ASLR does not randomize data segments - there's no need since the original intent was to make executable locations hard to guess. Non-executable locations was not the problem ASLR tried to solve.

            And in the case it would not matter at all if the location was randomized, since t

    • Re: (Score:2, Informative)

      by Anonymous Coward

      Existed != Known. Unknown if known until now.

    • If only they had written OpenSSL in Java instead of C! I'm wondering how many friends I can get on Slashdot with that statement.

      ..., I think that we need to do three things:

      1) Pay money for security audits of critical security infrastructure like OpenSSL
      2) Write lots of unit and integration tests for these libraries
      3) Start writing alternatives in safer languages

      Given how difficult it is to write safe C, I don't see any other options. ...

      (from [],

    • by Lennie ( 16154 ) on Tuesday April 08, 2014 @10:53AM (#46694121)

      "known for 2 years"

      No, no, this has been the code part of the stable release of OpenSSL for 2 years. The bug has only been known by non-blackhats for up to a few weeks.

      If anyone else like a blackhats or NSA or whoever knew about the bug before hand, we don't know.

  • by skids ( 119237 ) on Monday April 07, 2014 @08:07PM (#46689605) Homepage

    Who knows who knew what and when, but the 2012 statement is a misinterpretation of TFA where they seem to be saying it essentially started "hitting the shelves" in distros about then, whereas before then it was mostly only distributed in beta builds and head code.

    • by Bite The Pillow ( 3087109 ) on Tuesday April 08, 2014 @12:20AM (#46690979)

      Context: "Bug was introduced to OpenSSL in December 2011 and has been out in the wild since OpenSSL release 1.0.1 on 14th of March 2012. "

      After so many years of this shit, it has to be intentional, just so people will post corrections.

      • by FriendlyLurker ( 50431 ) on Tuesday April 08, 2014 @04:02AM (#46691791)

        After so many years of this shit, it has to be intentional, just so people will post corrections.

        Of course it is intentional, and yet no naming and shaming appears to be going on... why is that? Only a small handful of people are responsible for bringing this to our linux distros, and a few more responsible for keeping it there. Those people have lost the trust of the community and should never have any of their code submissions or bug priority lists accepted ever again, otherwise there is just no consequence for nefariously subverting the security of us all.

      • by skids ( 119237 )

        I don't think so in this case. I normally would have waited on the firehose for a submission with a better writeup, but this was relatively urgent news so I upvoted it anyway.

        (Yes someone did understand you weren't talking about the potential intentionality of the bug, don't despair there are people capable of comprehension out there and you may even meet one face to face someday :-)

  • by s.petry ( 762400 ) on Monday April 07, 2014 @08:11PM (#46689633)

    Now how are we supposed to collect people's private information without their knowledge? Think of the children and all of the terrorists captured with this exploit in the wild!


  • by sk999 ( 846068 ) on Monday April 07, 2014 @08:22PM (#46689705)

    Never trusted openssl - only use GnuTLS. []

  • As I can't imagine the servers I connect to being interested in snooping on my client data, I presume this bug is only a real concern for systems running services, not acting as clients.

    • by paskie ( 539112 )

      I *think* it might be feasible to exploit your web browser to steal cookies or saved credentials if you connect to a rogue https site. Credentials are always nice for spamming. If you convince people to keep you open in another tab, you might get lucky and snoop some credit card numbers or banking credentials too. A regular person should fear mainly automated attacks like this.

      (Please do prove me wrong if I didn't get the attack potential here right.)

      • No, you got it quite right. A server could grab browsing history, JS memory contents, stored passwords, and authentication cookies from a browser. It's not just web browsers, though; a malicious server could also steal email (from other email accounts) out of a mail client, and so on. For the handful of services that use client certificates, a server could steal the *client's* secret key.

        Browsers (or other clients) that use multiple processes have some degree of safety, as this exploit can't read across process boundaries. It's also completely passive; just because every Chrome tab *can* get the cookies that are currently being used in every other Chrome tab doesn't mean that they are always loaded in each tab's process' address space (though I don't know if they are in practice or not).

        Still, this is a grade-A clusterfuck security-wise. The ability for an unauthenticated attacker (all you need is an open TLS connection; that could be the login screen) to read memory off the other side of the connection is the kind of exploit you can make movie-grade "hacker" scenes out of. For a simple example you might see somebody pulling, you could use this exploit to decrypt any connection you recorded, assuming the server hadn't rotated its private key since then. If you can be fast enough and are in an intercept (MitM) position rather than just monitoring passively, you could even grab the keys in real-time and have complete control, invisibly, over the connection. From there, you could even read memory from the client and (continue reading from) the server at the same time!

        You could probably do it automatically using a Raspberry Pi hiding behind the flowerpot in a café. I'm not joking.

        I've been in the security world for years and I don't think I've ever seen so bad a vuln. Yes, things like "goto fail" were mind-blowingly stupid, but they still only let you MitM connections if you were in the right place at the right time. This one is strictly better and enables a huge number of alternative attacks.

    • by skids ( 119237 )

      You really think the guy behind is trustworthy?

    • If you store data on servers (hello cloud) then as a client you should be concerned.
    • by AHuxley ( 892839 )
      It really depends on the end game for *you*.
      Client data might be used for "full spectrum" efforts e.g. propaganda, deception, mass messaging, pushing stories, spoofing, alias development or psychology.
      i.e. the service you use is weekend.
      The other aspect is how many groups knew of this crypto trick? The US and just a few friendly govs, their staff, their contractors and any ex staff or staff open to faith or cash needs.
      Just another way in :) []
  • Nobody tell the NSA about this, okay?
  • by Anonymous Coward on Monday April 07, 2014 @08:39PM (#46689843)

    can someone link to the git blame of the bug please?

    • by Anonymous Coward on Tuesday April 08, 2014 @03:22AM (#46691645)

      There's an analysis of the bug here [].

      • by dkf ( 304284 )

        Mod parent up; it's very informative and worth reading.

        Whether you get anything truly interesting out of the attack is a separate matter. Fortunately, the attacker can't control where the read is from (just its length) so you're more likely to get the session key (which the attacker will have anyway) than the private key from this sort of poking around around.

        Beware memcpy()! If you don't know exactly where you're reading from and writing to and that you've got big enough memory chunks at both ends, you've

  • Is this for real? (Score:5, Interesting)

    by WaffleMonster ( 969671 ) on Monday April 07, 2014 @08:40PM (#46689849)

    Is there anyone on the planet using TLS heartbeats via TCP for anything except exploiting this bug? What is even the point of heartbeats without DTLS?

    Bugs are bugs yet decision to enable a mostly useless feature for non-DTLS by default in my view is not so easily excusable.

    • Re: (Score:3, Informative)

      by Anonymous Coward

      It's disabled in the base system OpenSSL in FreeBSD, so it can't be that critical.

      Incidentally, that also means that the summary is ... imprecise: FreeBSD, by default, isn't vulnerable to this. If you have OpenSSL from ports installed, it is - though that also means the fix is a simple package/port upgrade. (The fixed version is in ports already, and packages are, I believe, being built.)

  • by steelfood ( 895457 ) on Monday April 07, 2014 @08:41PM (#46689857)

    Well, it's not good that almost every major audit-able crypto library has been found to have trivial exploits (still waiting on issues in the Chrome and Mozilla SSL libraries).

    It's good that eyes are looking, and people are finding these things. I imagine that without Snowden's revelations, nobody would have bothered to check. And these bugs would have been found much later or not at all, allowing espionage organizations to compromise many more private communications in the interim.

    While the idea that the NSA or some other agency had a hand in these bugs is largely a conspiracy theory, the answer to whether they knew about these flaws and exploited them should be pretty obvious. After all, the NSA has probably done the very same code audits for the purpose of finding holes they can exploit.

    And before somebody says a closed-source implementation wouldn't suffer these problems, quite frankly, if all of these libraries were closed-source, we wouldn't know if there was a vulnurability at all, or for that matter if any found would be fixed. There needs to be more eyes auditing the security code, not fewer.

    • Chrome just uses the operating system for a lot of the certificate validation of HTTPS, so it can be vulnerable to security holes that apply to the operating system. Chrome wasn't vulnerable to "goto fail", but presumably it has been vulnerable to others in Windows and Mac OS.

      • by steelfood ( 895457 ) on Monday April 07, 2014 @10:19PM (#46690283)

        My understanding is that Chrome and Mozilla both use NSS. It's a bit outdated, so I could be wrong (given that Google forked webkit, I can imagine them forking NSS too).

        Actually, with a quick Google search, it seems that Chrome on Android uses (used?) OpenSSL for certain functions. I'm curious to know if secure communication via Android devices can be compromised via those functions. At first glance, I'd say no, but I don't have enough domain knowledge to make this assertion.

        NSS is thus far secure, but I really, really would like to see the results of multiple full and independent audits. If there's a problem in NSS, that would be about as big as it can get.

        Like I said, it's a bit frightening that there are such large and somewhat obvious holes in these major crypto libraries found within three months of each other, but it's good to know that they're being found and fixed.

    • While the idea that the NSA or some other agency had a hand in these bugs is largely a conspiracy theory

      Did you miss all the RSA stories?

      Whether they had a hand in this particular bug is conjecture. Whether they've had a hand in this sort of thing in general? They have.

  • Linux Mint, and I'd assume Ubuntu too, has already pushed the updates out. Happy happy. Joy joy.

    • by ewhac ( 5844 )
      For Linux Mint v17 (Qiana), maybe. However, Mint v15 (Olivia) got EOLed in January, so it may not get an update.
  • We're all fucked (Score:5, Interesting)

    by mveloso ( 325617 ) on Monday April 07, 2014 @08:56PM (#46689943)

    Any data kept in RAM on an open-ssl box has probably been compromised. It sounds like that includes private keys, root certs, passwords, etc.

    This is why passwords etc should be encrypted in RAM. It's funny, there's a Security Technical Implementation Guides (STIG) on that very item. It always sounded sort of ridiculous, but now I know why it was there.

    • No, "just" memory of the program that runs with libssl and to which attacker connected via ssl.
      There would need to be other exploits to cross program-program and user-user isolation.
      (well and the data/mem mapped/read/accessed by the compromised program)
    • Re:We're all fucked (Score:5, Interesting)

      by cbhacking ( 979169 ) <.moc.oohay. .ta. ... isiurc_tuo_neeb.> on Monday April 07, 2014 @11:26PM (#46690651) Homepage Journal

      Don't just encrypt them - move them out of process entirely. Have a security broker that knows your secrets, but doesn't talk to *anything* except local clients (on the assumption that if the attacker has arbitrary code execution, it's game over anyhow). Use inter-process communication to get secrets when needed, but preferably don't *ever* hold sensitive data in memory (for example, instead of using your private key directly, you ask he broker process to sign a binary blob for you, and it does so using your key and returns just the signature). Use "secure buffers" in managed code, or "secure zero" functions otherwise, to eliminate any sensitive data from memory as quickly as possible.

      Yes, this used to sound paranoid. Actually, it still does sound paranoid. But, there's now a great example of a scenario where this is a Good Idea.

      Of course, you have to make sure that broker is Really Damn Secure. Keep its attack surface minimal, make sure the mechanism by which it identifies whose key to use is extremely robust, and if possible make it a trusted part of the OS that is as secure from tampering as possible (Microsoft already has something like this built into Windows). There's also a question of how far to take it. For example, you could have the broker handle the symmetric encryption and decryption of TLS data (the bulk data part, after handshaking is completed) but that could impact performance a lot. Keeping the symmetric key in memory isn't so bad, really; it's ephemeral. However, if an attacker has a vuln like this and wants to read the traffic of a target user, they could attack the server while the user is using it, extract the symmetric key, and use it to decrypt the captured TLS stream. Keeping the key in-memory only while actually losing and (securely) purging it between response and the next request might be a good middle ground, perhaps?

      • by Viol8 ( 599362 )

        "Of course, you have to make sure that broker is Really Damn Secure. Keep its attack surface minimal, make sure the mechanism by which it identifies whose key to use is extremely robust, and if possible make it a trusted part of the OS that is as secure from tampering as possible"

        So in other words run it as root so when it gets compromised you're TRULY fucked. Yeah , genius idea. Far better is just to scatter parts of the password randomly around a block of memory and reassemble when required then delete wh

    • by maswan ( 106561 )

      Any data? From a vulnerability that can read up to 64k in the process that does the TLS heartbeat? Not even with a choosable offset.

  • All those links (Score:4, Interesting)

    by Arker ( 91948 ) on Monday April 07, 2014 @09:08PM (#46689997) Homepage
    But the actual announcement is not among them.
  • Windows (Score:5, Funny)

    by Kaenneth ( 82978 ) on Monday April 07, 2014 @09:34PM (#46690091) Homepage Journal

    Good thing I use WIndows, so I'm safe.

  • Does this effect SSH at all? It seems more likely this would effect TSL servers such as Apache and stunnel.

    • by skids ( 119237 )

      For sshd there was possibly some protection afforded by the privilege separation model. I'd store your old keys and wait to see something from someone who knows it cold.

      • Assuming it uses a version of openssl that supports the relevant TLS feature, SSH servers are absolutely vulnerable. Connect to one, carry out the attack while it waits for you to authenticate; now you can steal its secret key. This is also a way that a malicious SSH server could attack the client; possibly stealing things like the client private keys (SSH being one of relatively few places where asymmetric client authentication is common).

        • Re:Is SSH affected? (Score:4, Informative)

          by Anonymous Coward on Tuesday April 08, 2014 @12:32AM (#46691035)

          OpenSSH uses the libcrypto portion of OpenSSL for crypto primitives. It does not use TLS, and therefore SSH is not vulnerable to this attack.

          Shut the fuck up when you don't know what you're talking about.

          • Re: (Score:3, Insightful)

            by Anonymous Coward

            Rather than get all aggro, I will state that I have tried to find a concrete answer to this question ("is OpenSSH vulnerable/impacted by this?"), and I still cannot. So before someone say "shut the fuck up when you don't know what you're talking about" to me, I'll provide the data (and references) I do have:

            * OpenSSH links to the shared library which is absolutely OpenSSL on most systems: ldd /usr/sbin/sshd followed by strings /whatever/path/ (you'll find OpenSSL references in th

    • As I understand it, this is a bug in a function of OpenSSL that is used in TLS sessions which isn't used by OpenSSH. OpenSSH does not use TLS.

      Your webserver and mail server would though.

  • by rabtech ( 223758 ) on Monday April 07, 2014 @09:42PM (#46690135) Homepage

    Yet again, C's non-existent bounds checking and completely unprotected memory access lets an attacker compromise the system with data.

    But hey, it's faster.

    Despite car companies complaining loudly that if people just drove better there would be no accidents, laws were eventually changed to require seatbelts and airbags because humans are humans and accidents are inevitable.

    Because C makes it trivially easy to stomp all over memory we are guaranteed that even the best programmers using the best practices and tools will still churn out the occasional buffer overflow, information disclosure, stack smash, or etc.

    Only the smallest core of the OS should use unmanaged code with direct memory access. Everything else, including the vast majority of the kernel, all drivers, all libraries, all user programs should use managed memory. Singularity proved that was perfectly workable. I don't care if the language is C#, Rust, or whatever else. How many more times do we have to get burned before we make the move?

    As long as all our personal information relies on really smart people who never make mistakes, we're doomed.

    • by msauve ( 701917 )
      MS-BASIC, FTW!
    • Its probably possible to create a compiler mode that will compile bounds checking code into existing C programs. This would involve one compiler pass that would generate C output with the inserted code, and a second pass to generate the binary. This could be done with a new backend in Clang. It would also allow the inserted code to be easily seen since the source output could be dumped into a file. A good thing about this is that such a feature could be turned on or off in the compiler. This would be on by

      • There are lots of bounds checking libraries that can be used when building applications. The hard part is writing unit tests to find all these possibilities each time a patch is submitted.

    • by skids ( 119237 )

      Only the smallest core of the OS should use unmanaged code with direct memory access. Everything else, including the vast majority of the kernel, all drivers, all libraries, all user programs should use managed memory.

      My computer is too busy calculating an MD5 in a managed memory VM that doesn't even have an unsigned or sized integer types and thus must perform basic left barrel roll operations in about 50 opcodes worth of abstraction container dereferencing, to allow me to respond to this post appropriately.

      • Blah blah blah.

        Java 8 has a full SSL stack written in Java itself, so no buffer overflows there, and which uses AES-NI for hardware accelerated encryption if available. It also supports perfect forward secrecy and other modern features (no session tickets though).

        If you look at the CVE history of JSSE what you will find is that occasional bugs like the Heartbleed attack (not checking length fields correctly) get reported as denial of service issues because they cause managed exceptions that might, if you wr

    • Yes, bounds checking is a hassle in C but throwing out the whole language isn't necessary. We could default to smart pointers and add a new type qualifier for people who want the old behavior. Dangerous code would look like:

      int unbound * foo=malloc(1024);

      It might be required to have a compiler switch to avoid breaking ABIs that are expecting simple pointers. The bounded pointer would have to be a struct with a slim pointer and a size in it that gets updated whenever the pointer mutates, and raises a si

    • Feel free to rewrite OpenSSL in a more secure language and still make it as generic and cross-platform as it is now, with no loss in performance.

    • I don't understand why this is controversial. People consider it a bad idea to roll your own encryption code. Why isn't it a bad idea to roll your own bounds checking? Because it's easy and you won't screw it up? I'm sure people writing their own hash functions feel the same way.

      Do people seriously prioritize speed over security? Of all of the things my computer might squander its gigahertz on, squandering them by checking bounds on things that will never actually be out of bounds isn't something I can

  • Yes!!! (Score:5, Funny)

    by Areyoukiddingme ( 1289470 ) on Monday April 07, 2014 @09:45PM (#46690145)


    I knew procrastinating Debian upgrades for most of a decade would pay off! I am VINDICATED!

  • There are security vulnerabilities seemingly EVERYWHERE. Do programmers not test their code anymore? Is there no testing protocol for security issues? Is no one embarrased to have released a piece of software that's so porous? I'm retired, and I can tell you that if I had written code with the security holes that modern programs and apps seem to have, I would have been unceremoniously fired very quickly by any and all of the several employers for whom I worked in my career. But that doesn't seem to happ
    • by skids ( 119237 ) on Monday April 07, 2014 @11:20PM (#46690619) Homepage

      There may seem to be more now because there is more auditing going on since the NSA revelations reminded people what had to be done, and also the slower trend of case law starting to punish mishandling of customer data. The halcyon days are over and the backlog is being cleared up.

    • by putaro ( 235078 )

      Yah, like all that oh-so-secure code that used to float around back in the 70's and 80's? I remember when systems used to get hacked by dial-up modem on a regular basis. There were and have been security holes in things forever. It just used to be harder to exploit most of them remotely and there were fewer people trying to exploit them.

    • Is there no testing protocol for security issues?

      A lot of open source code is just thrown out there with the hope of enough random people reviewing it: "with enough eyeballs, all bugs are shallow". The testing protocol you are thinking of is instead called professional code audits. That's what OpenBSD does, and it's what Microsoft puts a lot of money into. It's basically paying for the eyeballs, to ensure that those eyeballs actually exist and are possessed by competent people.

  • by 93 Escort Wagon ( 326346 ) on Monday April 07, 2014 @10:52PM (#46690473)

    But, regardless of the root cause (intentional malice or just sloppiness) I'm glad eyes have been checking these code bases with more diligence over the past several months. In the end it means more security for us users, regardless of our platform of choice.

    Thank you again, Edward Snowden, for the collective wake up call!

    Now if we could just get our governing officials to fix some of these egregious laws...

  • by seifried ( 12921 ) on Monday April 07, 2014 @11:54PM (#46690841) Homepage

    RHEL updates are available: []

    CentOS updates are available: []

    Fedora updates are available, hitting the mirrors, but you can get it earlier, instructions here: [] []

  • To get your version, run:

    openssl version

    Yes, I looked it up... in hindsight, I guess it was kind of obvious and I should have been able to figure it out. Anyway, it's done. Hope it saves someone a few seconds....

  • by StormReaver ( 59959 ) on Tuesday April 08, 2014 @07:15AM (#46692405)

    Distributions using OpenSSL 0.9.8 are not vulnerable

    This is why I haven't upgraded my Linux servers in 23 years.

  • by monkeyhybrid ( 1677192 ) on Tuesday April 08, 2014 @10:36AM (#46693927)

    Filippo Valsorda's online tool for checking web servers for the Heartbleed vulnerability [] is quite an eye opener. As well as telling you whether the server is vulnerable, it displays a small snippet of the memory it retrieved (there are scripts on Github that will show you the whole 64KB I believe).

    In the quick tests I did on (used for Yahoo's email and probably all other Yahoo services), I saw three different user's passwords and at least part of their usernames. And you can just sit there refreshing the page to see more! Madness!

  • by Indigo ( 2453 ) on Tuesday April 08, 2014 @10:43PM (#46701361)

    Does anyone else see anything odd about the search results for this story?

    I Googled "heartbleed" around 15 minutes ago and looked through 13 pages of results. I was looking for some info a little on the hardcore side, and the Google results were kind of surprising. There were tons of big well-known sites at the very top of the list - Fox, CNN, BBC News, Reuters and Forbes, etc; then a whole lot of mainstream "tech news" sites (PC World, ZDNet and so on) and blogs (HuffPo for example), then finally some more tech oriented or actual tech ones (YCombinator, Netcraft, StackOverflow) with a tiny sprinkling of blogs and relevant support forums (Cisco). US-CERT's listing was down on page 3 or so and honestly there just were not that many "hardcore" sites to be seen.

    Running the search again after clearing cookies, the layout has changed a lot. The big news sites hits have slid way down (Fox News is on p. 3 now, for instance) with tech news and blogs moving up. All in all, the harder tech sites are floating upward and the less so are moving down. It's like the lava lamp version of a security scare.

    Wondered what other Slashdotters think, it just seems a bit... strange, somehow. Don't these things usually bubble around in the tech community for a bit before surfacing in the mainstream world? It's like every big news site on the planet picked it up simultaneously, followed by the mainstream tech news site, and finally it began to filter down into the tech world. Could just be an artifact of Google's update cycle, but it definitely piqued my curiosity.

Recent investments will yield a slight profit.