Skip to main content

View Diary: The MSFT-NSA conspiracy theory (40 comments)

Comment Preferences

  •  I'm sorry (1+ / 0-)
    Recommended by:
    DeadHead

    You contradict yourself.

    (There is, by the way, a really good reason for this.  Large entities have large bespoke packages running on Windows, and those packages can break when a patch is installed or a work-around is applied.  Big users, in particular, need time to test packages before they go out, lest they be left off-line after the package is applied, or, worse, remain vulnerable.)
    But how does releasing the patch/vulnerability details to big organizations early help them roll out the patch any faster as opposed to just releasing all the information/patches as soon as possible to everyone?  The only counter response is that releasing the information/patch makes the vulnerability easier to exploit.  Therefore you are attempting to buy time before the details are known.

    But then you argue in (3) that knowing the details doesn't really help the hackers since they already know them.  Then why delay the release?

    I'll grant that it is likely more about blackmailing people into buying support contracts than a secret plot to help the NSA.  But that doesn't mean it is completely benign.

    •  I don't contradict myself (1+ / 0-)
      Recommended by:
      emelyn

      In fact, yes, the very release of a patch does make the vulnerability easier to exploit.  Using binary diff tools on the patch itself points at the places where the vulnerability might be.

      What I argue in (3) is that the NSA (or any competent cracker ring) has a dictionary of vulnerabilities it has already found and for which it has already written exploits.  Those folks aren't going to be helped by being told about any vulnerabilities Microsoft is about to patch -- they don't need them, as they've got their own.

      As to your comment about blackmailing people, that's just absurd.  Corporate entities buy support contracts for Linux, for heaven's sake -- and they can see its code completely!  Fixing a broken computer program is a black art, particularly when the reason that it's broken has only to do with the parameter settings.  (Should MAX_BUFFER_SIZE be 4M or 16M in /etc/my.cnf?  Yes, that will make all the packets fit, but it will also place a heavy burden on smaller packets.  How will that affect throughput?)

Subscribe or Donate to support Daily Kos.

Click here for the mobile view of the site