The death of 3rd party system tools?


A co-worker recently asked me what I thought about the upcoming hardening of the x64 versions of Windows, which makes it harder to write cool programs like Compuware’s SoftIce, or RegMon & FileMon from SysInternals. The gist is that Windows will attempt to block modification of  the IDT/GDT and the system call tables, except by authorized Microsoft hot patches.

I’m of mixed opinion on this.

The “Cools tools” part of me thinks this is a bad thing. A lot of awesome projects have come about only because of great tools that provided visibility into the system’s inner workings.

The other “OS purist” side applauds the Windows kernel team for making the OS that much better. (Almost) anything that improves robustness is a good thing, and I certainly want to run the best Windows possible.

On an internal email thread, a kernel guru dismissed these tools as “hacky”, and that was the nicer of the adjectives. They suggested that there are better ways to get similar functionality (such as filter drivers for the file system.)

There’s also a middle ground in my mind. To perform these hacks, these tools need sufficient access rights to load kernel mode drivers. If your running with enough rights to load a driver, (e.g., as Administrator) the driver can (mostly) party all over the kernel data structures. What if there was a special mode that needed to explicitly be enabled was available? This mode would turn off the hardening so that tools could muck about to their heart’s content. Something similar to this has happened already. In order to work on Windows XP, the SoftIce installation has to disable Window’s kernel page write protection. (Sorry, no links, and I don’t know the details.)

I personally have no direct control over any of this, as I’m not in the Windows group. I’m just an interested bystander in the discussion.

What’s your opinion?


Comments (24)

  1. A world without those 3rd party debugging tools is a world full of pain if you start having problems with your system, a 3rd party app, or your own code.

    I use the sysinternals tools all the time.

    It might make much more sense to have something similar to what VS2k3 does right now – that is, a debugger account which has the rights to do these kinds of things.

  2. Nick Parker says:

    I think the key is "except by authorized Microsoft hot patches". If the functionality will exist to modifying system service tables via Microsoft hot patches, what would stop the third parties vendors from mimicking the access to the system tables that the hot patch provides?

  3. Chris Bilson says:

    What if Microsoft just made it easy for the "cool" tools to get authorized? I only use "cool" tools from a handful of places anyway. I know some of those places’ tools are even referenced in KB articles. Why doesn’t Microsoft offer some option to the developers of those tools?

  4. Anthony Eshpeter says:

    I think Microsoft needs to look at these tools as an indication of a lack of functionality within the Operating System itself.

    Has anyone tried opening a COM port to find out "another application or telephony device" may be using it? How come I can’t go find out who has ownership of what resources on my PC?

    How about IP connections and ports? I know I can get information using the netsh interface, but how come I can’t get a summary in my network connections?

    Wouldn’t security be easier if we could easily assess what has control of what parts of our system?

    To answer these questions, I go to "cool tools". But man, I think these need to be part of the operating system.

  5. Shay Erlichmen says:

    The problem with integrating functionality into the OS is that you are always one step behind the creativity of ppl. Lets say the LH will have build in all the tools the SysInternals/NuMega (+Many others companies) gave us. What about the next set of tools that nobody invented or even thought about? Anyways it’s a big world out there and it’s a big OS so ppl will always find a way to *hack* into.

    P.S. Matt I think that the page write thingy that you are talking about started in NT5.

  6. Adam says:

    When we didn’t protect against these bad activities, people would run these things, crash, and then blame us. Hacking up the operating system in the way that some of these apps were doing is highly error prone, guaraunteed to break the next time the compiler or OS changes, and generally not worth it. Tell us the interfaces you need to accomplish your task and we’ll try to put them in in such a way that you can’t shoot off your foot or worse deploy a product that shoots off a lot of feet.

  7. Dmitriy Zaslavskiy says:

    1 >Tell us the interfaces you need to accomplish your task and we’ll try to put them in…

    2 >Use filter driver…

    1. Will take forever to implement, delays will be infinite and only certain companies will get enough presence to effect anything.

    2. Filter driver DDK costs. Which once again will have effect on the number/price of tools available.

  8. Tonetheman says:

    The truth is, MS needs 3rd party tools and they are foolish and arrogant to think that they do not. An OS without choice is not going to make developers happy. If I had to wait on MS to get a C++ compiler correct I would have had to wait until .net… Regmon, filemon, ethereal, softice and others are essential programs to debugging crappy software and in some cases a crappy OS.

  9. Bart Vries says:

    Most of the tools that would suffer from these changes would be debugging and problem solving tools. Even if MS would add their own versions of those tools to ResKit there will be gaps that need to be filled. The main thing is that you don’t want to allow ‘normal’ users to do bad thing. So what if all accounts on a box or network would basically de disallowed running those tools. On an XP box even the users extra users with admin rights would be disallowed. Only the root account would be able to give these users the rights to run these tools (and super domain admins). This would prevent ‘normal’ users to do anything they should not, but would allows ISV to temperately give those rights so they can trace problems. If possible even with extra warning dialogs. Maybe MS needs to change the way the user accounts are setup or impersonation can be misused to give rights, but it would be better than removing support for tools that are commonly used.

    I think this would make everybody happier and keep to OS as flexible as possible. They could even add raw sockets back if the right was given. πŸ˜‰

  10. We *do* need those kind of tools. I’m not really too concerned about *how* they are implemented, but we *do* need the functionality. At a minimum there needs to be a developer/soften mode where these tools can function.

  11. JimA says:

    I think Mark over at sysinternals is resourceful enough that he will continue to provide cool and useful tools, no matter what Microsoft does with the OS.

    On the other hand, who can blame Microsoft? Most of the OS crashes I’ve seen are bad 3rd party drivers. I used to work with a guy who did video drivers and he liked to talk about the disgusting hacks he’s done in order to achieve a 0.003% increase in Quake II frame rates. Some hardening of the OS wouldn’t hurt to put an end to these cowboys.

  12. DrPizza says:

    I think it’s utterly futile.

    Whatever the OS tries to do, ring 0 code will be able to undo. It might be fiddly, but so what? It’ll happen. If nothing else, root kits will do it.

    If they want to forbid WHQL drivers from doing these things (which I presume they do already), great. Let them do that. But third-party uncertified applications? MS don’t support them anyway; they don’t guarantee them anyway; if they crash the OS, that’s not MS’s problem. I don’t, therefore, see any sound rationale for these changes.

  13. DrPizza: "if they crash the OS, that’s not MS’s problem"

    Sadly, people will blame MS even then. Yes it’s not supported, but it SHOULD work with their OS and damn MS for making it not work.

    Security is really what we’re talking about here. Because of security concerns, MS is dropping access to certain low-level stuff. Rather than rethink their "Administrator 0wnz" model, they’re coding around it to make sure that Administrator still is king. I think MS will understand eventually that least priveledge and levels of security are ideal but until then they’re going to try to patch the problem with as many bandaids as they can find.

    I second your comment that there is no sound rationale for these changes. I wonder what kind of "intense developer meetings" they had discussing this one. It’s kind of sad when you can invision meeting upon meeting of them discussing pros and cons then finally deciding on something as retarded as this. Kind of makes me glad that I’m not a manager there.

  14. Skywing says:

    I think this is a rather stupid change. People are just going to come up with even worse hacks to subvert the protections in the new kernel, which is just going to make the problem worse.

    <rant>

    DrPizza brings up a good point, too – the same problem exists with Microsoft blocking raw socket sends on Windows XP service pack 2. This is completely self-defeating, as you already need administrative privileges to open a raw socket in the first place. If you have administrative access, then you can load a driver and bypass the limits that way. To make matters worse, this was aimed at stopping the *bad guys*, who install zombies that spoof their IP addresses using raw sockets to perform DDoS attacks. Now, I don’t know about you, but I don’t think the bad guys are going to give up and say "well, we’ll just not start putting kernel mode code on people’s machines so that we can spoof IP addresses, because we’re nice people". Sure, it might stop *legitimate* users of raw sockets, who might not want to be mucking around in kernel mode without good cause, but the bad guys? Give me a break. All this does is provide MORE incentive for the bad guys to install malicious kernel level code.</rant>

  15. Anon says:

    I live and code by tools like FileMon and RegMon, and if third-parties (as much as they may try, MS can never provide everything) such as SysInternals were prevented from providing such tools, it would be a sad day. And they shouldn’t have to pay or register with MS, either.

    Improving security is great, and making it more difficult for the people to do "bad" things is fine, but there should always be an admin-controlled mechanism for allowing dev and system tools.

  16. Bob Arnson says:

    http://frontline.compuware.com/nashua/kb/doc/857.asp — old, but still accurate, as of [4.]3.1, at least.

  17. David Levine says:

    MSFT is good at providing systems that are good enough that people want to use them, but they typically do a really crappy job at supplying the tools that are needed to use or manage it. Case in point: after 15 years all they have to edit the registry is regedit, which is basically little more then a hex editor. Or why does TaskMgr show nothing more then the image name in the process view? Where is the binary at, who wrote it, what does it do, why is it there? In other words, where’s the context?

    Whenever MSFT comes out with a new OS they leave the field wide open for 3rd parties to write tools and utilities, because those that are supplied by MSFT are incomplete or so user-hostile they are practically unusable. There’s a reason why SoftICE exists, and I see little to make me believe that’s going to change. .NET should be a godsend to 3rd party developers – there’s lots of new tools that are needed.

    At least they’re willing to talk about providing interfaces to the low-level, and they do seem have opened up somewhat for .net – these are all encouraging signs. And I’m glad that Matt is now on the inside – perhaps he’ll be able to be an agent for change from within.

  18. SaD J says:

    maybe they want nobody to find foles in their OS with these tools and exploit it instead of making more secure OS ..

  19. kewl says:

    nice πŸ˜‰ kurwa πŸ˜‰