RE: [Full-Disclosure] M$ - so what should they do?

From: Eric Paynter (eric_at_arcticbears.com)
Date: 06/22/04

  • Next message: Eric Paynter: "Re: [Full-Disclosure] M$ - so what should they do?" 
    To: full-disclosure@lists.netsys.com
Date: Mon, 21 Jun 2004 21:21:26 -0700 (PDT)

    On Mon, June 21, 2004 3:55 pm, joe said:
    > I have written several registry editor type apps for customers, it is
    > simply another API. For me writing a text editor is the same as writing a
    > registry editor, in fact, the classes I put together treat them both very
    > similarly from code use perspective.

    You missed one significant point, though. In my 15 years of computer
    programming, I have never *had* to write a text editor. Whereas, you have
    had to write *several* (your word) registry editors. And the only person
    who needs to know anything about a filesystem API is a compiler
    programmer. The rest of us mere humans use the standard library of open(),
    close(), read(), and write() commands if we want to access files
    programmatically.

    One more thing, because of the complexity of the registry and removing it
    from the filesysem, in Windows, you need to learn the filesystem API
    (whatever that means to you) to get at the filesystem, the registry API to
    get at the registry, the COM API if you want to communicate between
    processes, and several application-specific APIs to programmatically
    configure most applications. In Unix systems, it's all treated as files.
    You use a common interface to use them all - open(), close(), read(),
    write(). How much simpler can it be? And the simpler it is, the less
    margin for error. And the less margin for error, the less risk of exploit.
    And that means better security... something to think about.

    And before you say you *can* configure apps by directly editing the
    registry, removing the need to learn all of those unique APIs (although
    still leaving you without a nice local IPC interface), you'd better check
    your support agreement on that. Even Windows is not supported by MS if you
    directly edit the registry. Most app vendors say you're on your own too if
    you do that... So good luck! Any bad move in the registry is like open
    heart surgery. The box may never boot again - I know, I've done it more
    than once.

    > 10 people on one machine all load the same app... Here is where the pain
    > comes in. That could be a terrible waste of space and resources, but from
    > a security standpoint, maybe they should all maintain all of their own
    > info for each instance.... But now what about security updates? You
    would > be updating 10 instances. Hmmm point/counterpoint. What wins?

    Wow, that is a problem. Thank God it simply doesn't exist on Unix systems.
    The system-wide configs go into /etc and the user-customized portions go
    into /home/username/.appname (remember earlier I said all you need to
    backup is /etc and /home to restore a Unix machine?). Users don't install
    their own applications because they simply cannot. If they want an app,
    they ask the sysadmin to give it to them. If you are the sysadmin, you
    install it in the system area and the users get access to it as required.
    Don't forget, Unix systems were multi-user over a decade before DOS was
    even conceived. All of these problems have long since been solved.

    The biggest problem with Windows is that it is a multi-user system built
    on a single-user foundation. (Yes, I know, the NT kernel was built from
    the ground up the be multi-user, but the system layout did not change to
    be consistent with that, so maintaining it still has the same problems.)

    > I think your copy protection scheme might be pushing it a bit. It isn't
    > much more work to capture registry mods and apply them to other machines.
    > One of my old jobs had a large part of my time making up software dist
    > packages that did just that. You capture the reg changes made, you capture
    > the file changes made, you throw it into a package to be deployed by SMS
    > or the perl dist method of your choice. If they were intending that to be
    > wholly magical and to block software copying, there wouldn't be APIs the
    > public would have available to go into it. This is more FUD/conspiracy
    > thinking.

    Yes, yes. I know. I did electronic software distribution in a windows
    environment of several thousand machines for many years. We started with
    sysdiff (remember that?), and then moved on to the SMS Installer. And we
    used GHOST to take full images for mass deployment of desktops. I know a
    million ways to capture an installation difference. But how many home
    users do? It was meant to be a deterrent, not a 100% success. Remember
    that before the registry, we didn't need tools like sysdiff.

    Anyhow, all that noise aside, I think it's safe to say that whatever the
    registry was intended to be, it was a complete and utter failure. There
    are more headaches over trying to figure some part of the registry than
    there ever were worrying about all those lost .ini files. And for some
    reason, large Unix systems with thousands of users don't have any of these
    problems. Go figure...

    Back to the topic: What should they do? They should do like Apple did:
    stop trying to re-invent the wheel and adopt a tried-and-true model that
    works. The Unix-like systems are simply easier to manage and safer. And
    Apple has made them as easy to learn as Windows, while being as easy to
    administer as Unix.

    By the way, I'm not saying we should all have Linux systems, or FreeBSD,
    or any one particular system. I think we should have a diverse set of
    systems from several vendors, but that can interoperate and have similar
    interfaces to ease the burden of management. Solaris and Linux come from a
    completely different code-base. They are vulnerable to completely
    different types of attacks. Yet the administration of the two is almost
    identical. A good blend of Unixes in an environment makes it safer.
    Windows adds complexity simply by being so different, never mind all the
    problems described above.

    -Eric

    _______________________________________________
    Full-Disclosure - We believe in it.
    Charter: http://lists.netsys.com/full-disclosure-charter.html

  • Next message: Eric Paynter: "Re: [Full-Disclosure] M$ - so what should they do?"

    Relevant Pages

    • Re: [Full-Disclosure] PLEASE QUIT YACKING ABOUT M$
      ... on in order to get the 5% exploits within a single post, or all posts. ... >> simply another API. ... >> registry editor, in fact, the classes I put together treat them both very ... > from the filesysem, in Windows, you need to learn the filesystem API ...
      (Full-Disclosure)
    • Re: Calling Still Image API in C#
      ... It appears that you are calling the API correctly. ... the interface in C# should be correct. ... recommending that you remove the registry key for your registered ...
      (microsoft.public.dotnet.framework.interop)
    • Re: Regarding the Power Management API
      ... does is make your power manager non-standard (and potentially means that, ... when Microsoft decides to use that API entry, ... Why not just create a DLL that implements the API that you ... anyone who cares that there has been a registry change and those that ...
      (microsoft.public.windowsce.platbuilder)
    • Re: Setting Special Folders
      ... > Favorite Folder path, it actually setting the Favorite Folder for all ... I'm trying to modify them in the registry. ... > IMHO this is even worse then using the API! ...
      (microsoft.public.dotnet.languages.vb)
    • Re: mscoree.dll creating new appdomain with local configuration
      ... I will have a closer look at the API you ... mscoree.dll would handle some undocumented registry entries. ... loaded, there must be a runtime and a appdomain, the ccw has to be around. ... use a configuration file for that appdomain. ...
      (microsoft.public.dotnet.framework.interop)