Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Security Bug Microsoft IT

Security Patch Creation at Microsoft 274

devonshire writes "Officials at the Microsoft Security Response Center have provided a detailed look at the process used to create security patches. From the time the first vulnerability data is received from grey hats to the time a bulletin is shipped, it's a pretty interesting look at how they handle the information flow and patch testing and why it takes so darn long to release an IE update."
This discussion has been archived. No new comments can be posted.

Security Patch Creation at Microsoft

Comments Filter:
  • Liars (Score:5, Informative)

    by cperciva ( 102828 ) on Friday June 10, 2005 @04:26AM (#12778110) Homepage
    Quoth the article:
    We respond immediately to the initial vulnerability report and provide the researcher with contact names, e-mail addresses and phone numbers. We make it clear we want to work closely with the researcher to pinpoint the problem and get it fixed. We commit to providing [researchers] with a progress report on the Microsoft investigation every time they ask for one

    My experience directly contradicts this on all points.

    When I reported the hyperthreading security flaw [daemonology.net] to Microsoft, I was provided with the first name of the person who was responsible for dealing with it ("Christopher"), but I was not provided with his last name, phone number, or any e-mail address (apart from the generic secure@microsoft.com address which I used to report the problem). Later the issue was transferred to "Brian" -- again, no last name, no email address, and no phone number.

    Over the following two months, I heard from three independent third parties that Microsoft was "very concerned" about this issue, and had "several people" looking at it; but they never made it clear that they wanted to work closely with me -- in fact, they ignored all my attempts at co-operation.

    Finally, prior to releasing my paper, I sent several emails to Microsoft asking about their progress and asking for a vendor statement for my web site; again, they did not respond.
  • And, what about selling a company the software and giving them the GPL (something YOU have to do if you are using the GPL as it sates that the software must come with its license). I wonder what would they say when they discover that the software they are buying at $5000 can be downloaded from sf.net

    Um, the GPL doesn't say that you have to give your code free to everyone on the planet.
    It says that you have to give your code free to anyone you sell the binary to... *if* the person ask for the code.

    so a company using internal GPL'd code does NOT mean that their code will be avaliable to their competitors, unless they sell their product to their competitors.

  • by SirCrashALot ( 614498 ) <{jason} {at} {compnski.com}> on Friday June 10, 2005 @10:35AM (#12779712)
    Maybe you can't but others certainly can, and if you are so inclined, you can learn.
    Also the fact that code is open makes the authors more careful, i would think. If I am going to publish code with my name on it, I would hope it doesn't suck.
    Closed source could have terrible code style and use all sorts of hacks, and no one would know. Or it could be perfectly written using Hungarian notation. With OSS, if you have bad code, people who can read it, will, and tell others.
    Besides, if you want, just do a search for printf and gets in the code -- you might find some bugs w/o having to write a thing.
  • Re:Right (Score:3, Informative)

    by deranged unix nut ( 20524 ) on Friday June 10, 2005 @11:06AM (#12779955) Homepage
    Testing only takes 10 minutes if your configuration has no complexity or interdependency.

    Note: I test software for a living.

    With the complexity of most fortune 5000 companies, for anything integral to networking or used as an interface between mulitple software applications, it could easily take months to make sure that a change doesn't break anything.

"If it ain't broke, don't fix it." - Bert Lantz

Working...