Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Friday May 09 2014, @02:50PM   Printer-friendly
from the the-gift-that-keeps-on-giving dept.

Ars Technica reports that four weeks after its disclosure huge swaths of the Internet remain vulnerable to Heartbleed. The article suggests that over 300,000 servers remain vulnerable.

What steps have you taken to protect yourself from this bug? What browser addons have you installed? Have you checked/updated the firmware on your home router? If you work in IT, what has the reaction been? Has your site been compromised? Has vulnerable code been updated, new keys genned, new certificates obtained, and old ones revoked?

Since the OpenSSL library is now undergoing a security review and a fork of it is underway as LibreSSL, it is possible that other vulnerabilities will be discovered. Then what? How likely is it that we will need to repeat this cleanup effort?

(more after the break)

The Heartbleed bug "is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet." The bug affects not only computer servers, but also routers and even some Android phones, too. Even software like LibreOffice, WinSCP, and FileMaker have versions with the bug and need to be updated. The history, behavior, and impact of this bug are well-explained and summarized on Wikipedia. Therein is this recommendation:

Although patching software (the OpenSSL library and any statically linked binaries) fixes the bug, running software will continue to use its in-memory OpenSSL code with the bug until each application is shut down and restarted, so that the patched code can be loaded. Further, in order to regain privacy and secrecy, all private or secret data must be replaced, since it is not possible to know if they were compromised while the vulnerable code was in use:[68]

  • all possibly compromised private key-public key pairs must be regenerated,
  • all certificates linked to those possibly compromised key pairs need to be revoked and replaced, and
  • all passwords on the possibly compromised servers need to be changed.

SN's coverage of this vulnerability includes:

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by NCommander on Friday May 09 2014, @07:57PM

    by NCommander (2) Subscriber Badge <michael@casadevall.pro> on Friday May 09 2014, @07:57PM (#41370) Homepage Journal

    THe thing is, SQL injections can be surprisingly hard to spot. I personally blame a lot of this on MySQL, which as the fisher price of databases made it close to impossible to use stored procedures, triggers, or any sort of database functionality without embedding the SQL directly into the application layer. Since MySQL proved to be exceedingly popular, there's an entire generation of devs who feel all SQL and shit should be in the application logic.

    Sanitizing SQL is not as straightforward as most people seem to believe, and a lot of apps seem to prefer writing their own sanitization code vs. using something pre-provided by the DB. Since there's a bunch of edge cases most people can miss, and it just takes missing one or two lines and boom, instant SQL injection.

    What surprises me is its not more common.

    --
    Still always moving
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by chromas on Saturday May 10 2014, @12:25AM

    by chromas (34) Subscriber Badge on Saturday May 10 2014, @12:25AM (#41442) Journal

    That's why god invented prepared statements. In-band signalling is the devil's work.