4 ms·

it looks like someone forgot to decrement a reference count where they should have. in microsofts defense, these kinds of bugs are extremely difficult to reaso

by munin 15y ago

it looks like someone forgot to decrement a reference count where they should have. in microsofts defense, these kinds of bugs are extremely difficult to reason about and I'm not aware of any product, service or technique that you can buy, train in, or subscribe to to enable your developers to accurately reason about reference counting and concurrency. microsoft spends more $ per loc on security than any other organization on Earth so if this slipped through their process, similar bugs probably slip through your processes too. there are countermeasures in place especially in windows 7 and forward that would make exploitation of this extremely difficult (aslr, safe unlinking in the kernel heap, etc).

ketralnis 15y ago
> microsoft spends more $ per loc on security than any other organization on Earth so if this slipped through their process, similar bugs probably slip through your processes too I agree in principle, but this is hardly the most accurate way to measure this
- munin 15y ago
  it isn't no, but ask yourself, "what more can I do?" fund academic research? fund industrial research? hire security consultants to do independent audits and assessments? develop a secure software development methodology? hire security professionals and have them interface with both my product developers and the security community? have professionals interface with the global security community and develop strong working relationships with "well known hackers", possibly even hiring some of them? invest in lots of applied research on making exploiting bugs in your software harder? invest in actually building the systems that the previously mentioned academic research theorized about to identify bugs in software that you write? oh, you did all of that? and more? and there are still bugs in your code? somehow I think this says more about the craft of developing software than it does about your company and culture ...
  - wwrap 15y ago
    It's not a secret that Microsoft's hiring practices are somewhat subpar and their internal organization is a mess. Am I surprised that a product got rushed out with major issues? Of course not, they do it every day.
    - josephcooney 15y ago
      Where is the evidence that it was rushed out?

by munin 15y ago

ketralnis 15y ago

> microsoft spends more $ per loc on security than any other organization on Earth so if this slipped through their process, similar bugs probably slip through your processes too I agree in principle, but this is hardly the most accurate way to measure this

munin 15y ago
it isn't no, but ask yourself, "what more can I do?" fund academic research? fund industrial research? hire security consultants to do independent audits and assessments? develop a secure software development methodology? hire security professionals and have them interface with both my product developers and the security community? have professionals interface with the global security community and develop strong working relationships with "well known hackers", possibly even hiring some of them? invest in lots of applied research on making exploiting bugs in your software harder? invest in actually building the systems that the previously mentioned academic research theorized about to identify bugs in software that you write? oh, you did all of that? and more? and there are still bugs in your code? somehow I think this says more about the craft of developing software than it does about your company and culture ...
- wwrap 15y ago
  It's not a secret that Microsoft's hiring practices are somewhat subpar and their internal organization is a mess. Am I surprised that a product got rushed out with major issues? Of course not, they do it every day.
  - josephcooney 15y ago
    Where is the evidence that it was rushed out?