Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Google Bug Microsoft Security Windows

Google Releases More Windows Bugs 263

An anonymous reader writes: Just days after Google angered Microsoft by releasing information about a Windows security flaw, they've now released two more. "The more serious of the two allows an attacker to impersonate an authorized user, and then decrypt or encrypt data on a Windows 7 or Windows 8.1 device. Google reported that bug to Microsoft on Oct. 17, 2014, and made some background information and a proof-of-concept exploit public on Thursday. Project Zero is composed of several Google security engineers who investigate not only the company's own software, but that of other vendors as well. After reporting a flaw, Project Zero starts a 90-day clock, then automatically publicly posts details and sample attack code if the bug has not been patched." Microsoft says there's no evidence these flaws have been successfully exploited.
This discussion has been archived. No new comments can be posted.

Google Releases More Windows Bugs

Comments Filter:
  • No evidence (Score:2, Funny)

    by Anonymous Coward

    Microsoft: "There's no evidence these flaws have been successfully exploited."
    Google: "Then why are you wearing that fake mustache and goatee?"

    • Re:No evidence (Score:5, Insightful)

      by RelaxedTension ( 914174 ) on Friday January 16, 2015 @12:59PM (#48830957)
      "Microsoft says there's no evidence these flaws haven't been successfully exploited."

      FTFY.
      • "Microsoft says there's no evidence these flaws haven't been successfully exploited."

        Regardless of their meaning that's a ridiculous things to say, obtaining evidence to show the flaws haven't been exploited is infeasible. It's like saying there is no evidence proving that god does not exist.

    • >> Microsoft says there's no evidence these flaws have been successfully exploited.

    • by v1 ( 525388 )

      Microsoft says there's no evidence these flaws have been successfully exploited.

      "...so we're going to wait until the bot herders have sucked in a few million more machines before bothering to patch it."

      WHAT is WRONG with you, ms?? If I'm reading that right, google is doing precisely what is necessary to light a fire under MS's ass to get the bugs fixed. It isn't really even that. They're basically telling us they don't consider it to be a big deal until it starts getting exploited. By making that comm

  • by 140Mandak262Jamuna ( 970587 ) on Friday January 16, 2015 @12:45PM (#48830765) Journal
    I wish Apple would also pitch in and find and publish bugs in both Windows and Android. And Microsoft to retaliate by finding and reporting bugs in Android and Apple. In the end we as consumers will benefit. This should be come the norm. No longer minor players report possible bugs and the clock does not run till the company "accepts" that there is a bug.

    Free markets! Competition!! That is what made America, what it is.

    I wish such fierce competition exists in all spheres of the economy.

    • sitting on a macpro here at work, I'd say let's just have Apple fix yosemite bugs and problems. Not worrying about a dust speck in someone else's eye while they have two by four in their own

      • Apple won't fix shit. Their team doesn't have the experience to deal with the complexity MS has to deal with. Jeez, they couldn't, even make iOS 6 run smoothly on the 3GS phone which turned most of those phones into slow ass pieces of shit. Don't get me started on the last big iOS release or the map issues they encountered!

        MAC deals with a very limited scope of hardware and a limited number of permutations which in turn reduces the complexity of any patch. MS on the other hand has to deal with billions of p

    • by handy_vandal ( 606174 ) on Friday January 16, 2015 @01:19PM (#48831175) Homepage Journal

      I'm reminded of Neal Stephenson's description of Shanghai banks on the eve of World War 2:

      Here you've got the Hong Kong and Shanghai Bank of course, City Bank, Chase Manhattan, the Bank of America, and BBME and the Agricultural Bank of China and any number of crappy little provincial banks, and several of those banks have contracts with what's left of the Chinese Government to print currency. It must be a cutthroat business because they slash costs by printing it on old newspapers, and if you know how to read Chinese, you can see last year's news stories and polo scores peeking through the colored numbers and pictures that transform these pieces of paper into legal tender.

      As every chicken-peddler and rickshaw operator in Shanghai knows, the money-printing contracts stipulate that all of the bills these banks print have to be backed by such-and-such an amount of silver; i.e., anyone should be able to walk into one of those banks at the end of Kiukiang Road and slap down a pile of bills and (provided that those bills were printed by that same bank) receive actual metallic silver in exchange.

      Now if China weren't right in the middle of getting systematically drawn and quartered by the Empire of Nippon, it would probably send official bean counters around to keep tabs on how much silver was actually present in these banks' vaults, and it would all be quiet and orderly. But as it stands, the only thing keeping these banks honest is the other banks.

      Here's how they do it ...

      Continue reading ... [cryptonomicon.com]

    • "he did it! he did it!" yeah, they're taught that song at birth.

  • by Lawrence_Bird ( 67278 ) on Friday January 16, 2015 @12:46PM (#48830771) Homepage

    but in principle I agree with what Google is doing. In effect they are trying to destroy the market for zero day exploits and forcing the companies involved to not site on their hands and hope nobody uses them.. like cybercriminals and the various three letter agencies.

    • by dwheeler ( 321049 ) on Friday January 16, 2015 @12:58PM (#48830951) Homepage Journal
      90 days is really long. The US CERT vulnerability disclosure policy is 45 days as described in http://www.cert.org/vulnerabil... [cert.org] (see that more more details). The problem is that you have to balance two conflicting needs; in the words of the CERT, "the need of the public to be informed of security vulnerabilities with vendors' need for time to respond effectively."
      • 90 days is really long. The US CERT vulnerability disclosure policy is 45 days as described in http://www.cert.org/vulnerabil... [cert.org] (see that more more details). The problem is that you have to balance two conflicting needs; in the words of the CERT, "the need of the public to be informed of security vulnerabilities with vendors' need for time to respond effectively."

        It's definitely a fine balancing act, and regardless your opinion on the Google vs Microsoft disclosure debate, I am glad that we are having a public debate about it.

        Vulnerabilities cannot really be effectively categorized (look at the attempts from MITRE, for example). Some are due to simple programming errors and can be fixed and rolled out immediately. Some are deeper architectural problems that, even if an "easy" fix, have a whole ecosystem of software built around that wrong behavior. A one-size-fits-a

        • Some are deeper architectural problems that, even if an "easy" fix, have a whole ecosystem of software built around that wrong behavior..

          Google, or the world, do not have an obligation to tolerate Microsoft's willingness to market a fatally flawed product because a whole industry "expects" to take advantage of an insecure feature. It is no different that a fatally flawed skyscraper design. When such a building or bridge comes about, the world doesn't require architects or engineers to keep quiet about a safety flaw, because people already use it. The owner/design company is required to produce an effective correction to the problem, or th

          • by sjames ( 1099 )

            I'm no fan of MS (and I'm sure my posting history will bear that out), but there are other considerations here. No, MS shouldn't get a complete skate on this. They have proven that they need their feet held to the fire to get things to happen. BUT, there needs to be some slack in the system. If they appear to have been working on the problem in earnest and have a release plan, it's worth giving them time to complete it.

            Unlike a building with a flaw, there aren't lives at stake here and releasing the details

      • 90 days is really long when you don't have a massive base to run testing and regression against. Let's just say that the fix is adding a bounds check to the input for a single function. The engineer assigned to the bug adds the bounds check and unit tests to make sure it behaves now. The fix is submitted to the build queue for the (let's say nightly) run to generate the next patch set, and the next production build for Windows. Now QA gets it, and being that this particular item failed for an input, th

        • by whoever57 ( 658626 ) on Friday January 16, 2015 @02:39PM (#48832241) Journal

          Then they run that test as part of their automated "Test Windows" run (which probably takes hours to do)

          I am going to nitpick on your analysis, but I have zero sympathy for Microsoft having (hypothetically) a test system that takes hours to provide a result. This is a company with billions of dollars available to it. Invest in more test hardware if the test systems take too long to run.

    • by quantaman ( 517394 ) on Friday January 16, 2015 @01:05PM (#48831029)

      but in principle I agree with what Google is doing. In effect they are trying to destroy the market for zero day exploits and forcing the companies involved to not site on their hands and hope nobody uses them.. like cybercriminals and the various three letter agencies.

      From the article:

      In the bug tracker for the impersonation vulnerability, Google said it had queried Microsoft on Wednesday, asking when the flaw would be patched and reminding its rival that the 90 days were about to expire.

      "Microsoft informed us that a fix was planned for the January patches but [had] to be pulled due to compatibility issues," the bug tracker stated. "Therefore the fix is now expected in the February patches."

      The next Patch Tuesday is scheduled for Feb. 10.

      So 90 days is an appropriate time to wait but not 106 days?

      It's not like MS was sitting on their hands, they made a patch but found problems in QA and had to do more work to get it working properly. I don't see the rationale for Google maintaining the hard 90 day deadline, maybe extensions allow some complacency on the part of the developer, but you're still not going to see them sitting on issues for months or even years on end. Meanwhile by publishing now Google has created one of two scenarios. 1) Users are going to be left vulnerable to unpatched zero-day expoilts, or 2) users are going to break their systems by installing broken patches.

      It's not clear to me how this is better than sitting on the issue for anther 26 days.

      • by Anonymous Coward on Friday January 16, 2015 @01:13PM (#48831107)

        This is a situation where the "slippery slope" argument really does apply. If Google is just going to sit on bugs until the vendor patches... they're going to end up with bedsores. And no one likes bedsores.

        Instead, they embarass the vendors a couple times, and once heads are pulled out of asses and people realize they're not screwing around, they start taking these things seriously.

        That's my guess, anyway.

        • If the vendor isn't responding, sure, publish after 90 days. If the vendor makes a habit of asking for one-month extensions indefinitely, publish. If the vendor has specific plans and schedules, and has a history of doing more or less the right thing, which describes Microsoft here, sit on the disclosure for a little more time.

      • From the article:

        In the bug tracker for the impersonation vulnerability, Google said it had queried Microsoft on Wednesday, asking when the flaw would be patched and reminding its rival that the 90 days were about to expire.

        "Microsoft informed us that a fix was planned for the January patches but [had] to be pulled due to compatibility issues," the bug tracker stated. "Therefore the fix is now expected in the February patches."

        The next Patch Tuesday is scheduled for Feb. 10.

        So 90 days is an appropriate time to wait but not 106 days?

        It's not like MS was sitting on their hands, they made a patch but found problems in QA and had to do more work to get it working properly.

        Technically, it should have been in the November patch set, they should have found the compatibility problem in testing (as they did), and the revised patch should have been in the December patch set. Then the clock would have run out.

        So basically the *did* sit on their hands -- for two months.

      • but in principle I agree with what Google is doing. In effect they are trying to destroy the market for zero day exploits and forcing the companies involved to not site on their hands and hope nobody uses them.. like cybercriminals and the various three letter agencies.

        From the article:

        In the bug tracker for the impersonation vulnerability, Google said it had queried Microsoft on Wednesday, asking when the flaw would be patched and reminding its rival that the 90 days were about to expire.

        "Microsoft informed us that a fix was planned for the January patches but [had] to be pulled due to compatibility issues," the bug tracker stated. "Therefore the fix is now expected in the February patches."

        The next Patch Tuesday is scheduled for Feb. 10.

        So 90 days is an appropriate time to wait but not 106 days?

        Here is what Google use to say (circa 2010) from most of the same people who make up the Project Zero team (Chris Evans, Michel Zalewski, and others) AFAIK.

        Rebooting Responsible Disclosure: a focus on protecting end users [blogspot.ca]:

        Update September 10, 2010: We'd like to clarify a few of the points above about how we approach the issue of vulnerability disclosure. While we believe vendors have an obligation to be responsive, the 60 day period before public notification about critical bugs is not intended to be a punishment for unresponsive vendors. We understand that not all bugs can be fixed in 60 days, although many can and should be. Rather, we thought of 60 days when considering how large the window of exposure for a critical vulnerability should be permitted to grow before users are best served by hearing enough details to make a decision about implementing possible mitigations, such as disabling a service, restricting access, setting a killbit, or contacting the vendor for more information. In most cases, we don't feel it's in people's best interest to be kept in the dark about critical vulnerabilities affecting their software for any longer period.

        Somewhere along the way they appear to have lost their senses, and enshrine 90-days as some written-in-stone deadline that makes no sense, and is counter to their stated objectives.

        Announcing Project Zero [blogspot.ca]

        ... Our objective is to significantly reduce the number of people harmed by targeted attacks. ...We will only report bugs to the software’s vendor—and no third parties. Once the bug report becomes public (typically once a patch is available), you’ll be able to monitor vendor time-to-fix performance, see any discussion about exploitability, and view historical exploits and crash traces.

      • by c ( 8461 )

        So 90 days is an appropriate time to wait but not 106 days?

        I wouldn't be surprised if there was a "give an inch, take a mile" kind of situation, where they tried allowing some flexibility and got into a cycle where the vendor kept requesting more time each time around.

      • It's not like MS was sitting on their hands, they made a patch but found problems in QA and had to do more work to get it working properly.

        And you actually believe that?

        Many times, patches are just punted to QA even thought the developer knows full well that they're not going to pass QA. After all, I should know, I'm a software developer myself. Also, I can tell you that finishing the last 10% of a project is always the hardest part. May be it's because we naturally like to work on the easiest parts of a problem first, or may be it's because we don't actually start understanding the real requirements until we're almost finished with the projec

      • The only reason its 106 days is because Microsoft doesn't send out patches when available but makes them 'convenient' on patch Tuesdays. If they felt like it, they could release that patch today.

    • No.

      In effect, and in actuality, Google is being competitive.

  • by gwstuff ( 2067112 ) on Friday January 16, 2015 @01:58PM (#48831681)

    > Microsoft says there's no evidence these flaws have been successfully exploited.

    Cleverly worded sentence intended to leave the reader with the impression:

    "We don't know that there has been a breach, therefore there hasn't been a breach"

    when it really means...

    "We don't know squat about whether there has been a breach. Maybe all hell has broken lose, and there's no evidence to contradict that either."

  • I’m reminded of the old “blackmail” skit from Monty Python. Just with less of Terry Jones’ ass hanging out at the piano. I like it!

  • When Google finds security bugs in Android do they publish it along with proof of concept after 90 days?
  • Releasing Windows bugs is Microsoft's job.

It's a naive, domestic operating system without any breeding, but I think you'll be amused by its presumption.

Working...