A Possible Cure for Exploitable Heap Corruption in Windows 7

7 Comments

1. 2009-12-30 10:25 pm

   mrhasbean

   …of the efforts Microsoft are putting in to fix long standing problems with Windows and kudos to them for listening to customers and putting the resources toward these fixes.

   There are some other companies – I’m looking at you Apple – who should be taking notes, and if Microsoft can just get the IE team to clean the wax from their ears…
• 2010-01-02 8:23 pm

  gustl

  Sorry, but the IE team is perfectly well doing what they are told to do by Microsoft upper management.

  Full support for the upcoming HTML 5 features and/or ACID 3 tested features is not done on purpose. They want to push Silverlight down the internet’s pipes, their latest attempt at getting control of internet protocols.

  As always, with failing market share they will fail, but first (as always) they have to find out about that the hard way.

  I hope, lots of web programmers just request the users to install the google chrome plugin for IE and be done with IE compatibility.
2. 2009-12-31 1:13 am

   gedmurphy

   Collectively, just the introductions to these new features by Russinovich and his partners consumed 11 hours over the first two days, all of that time with a standing-room-only crowd.

   This is wrong. I attended both of his sessions, each an hour and 30 long and I sat down with the rest of the room.

   (and also his workshop on the first day, but that was a wide coverage talk)

   Also, the title mentions a cure for an exploitable heap and the summary ignores that completely. Did I miss something?

   Edited 2009-12-31 01:15 UTC
• 2009-12-31 2:52 am

  kaiwai

  This is wrong. I attended both of his sessions, each an hour and 30 long and I sat down with the rest of the room.

  (and also his workshop on the first day, but that was a wide coverage talk)

  Also, the title mentions a cure for an exploitable heap and the summary ignores that completely. Did I miss something?

  How about reading the *WHOLE* article where the cure is noted on page 2:

  We introduced this thing called fault-tolerant heap,” stated Mark Russinovich. “The basic idea is, it’s monitoring for heap corruptions. When it sees a heap corruption in a process, it enables heap mitigations, then it monitors the effectiveness of that heap mitigation, and if it’s effective, it keeps it on. At the process shutdown, [FTH] is keeping a record of mitigations it’s detected it had to apply with stack traces, and then capturing that and sending it up to Windows Error Reporting, so that you’ve got a record of exactly where your application was causing a heap problem. And then we can look at it, see if it’s our code or your code [that’s to blame] (it’s probably your code) and fix it.”

  Edited 2009-12-31 02:53 UTC
• 2009-12-31 12:23 pm

  gedmurphy

  Please try to understand my point before coming back with a cocky reply.

  I was highlighting the fact that there was no correlation between the title and the summary. I had to read the article to find out what the title was refering to, which makes the summary pointless.

  I wasn’t critisizing, I was pointing something out which I found a little confusing.
• 2010-01-02 7:37 am

  Tuishimi

  But insulting or trying to aggravate other people is so much more fun!
3. 2010-01-02 11:36 am

   tuttle

   If only they would spend a similar amount of work fixing the longstanding performance and stability issues in the .NET framework.

   Windows 7 is really a great OS, but the only efficient way to code for it is to use C++. .NET is not stable enough for serious app devlopment (a fact that we found out the hard way). And in java/scala it is kind of hard to use windows-specific features because jni is a pain in the ass.

   See for example this inexcusable defect of the .NET heap management:

   https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.asp…

   Or the lack of inlining in all the places that matter with the 64bit JIT compiler:

   https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.asp…